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'     ^  ABSTRACT 

It  is  well  known  that  a  Translator  Writing  System  (TWS)  can,  in 
general,  be  divided  into  two  parts:  a  syntax  preprocessor  and  a  semantics 
preprocessor,  yielding  compilers  composed  of  a  syntactic  recognizer  and 
a  package  of  semantic  routines.  This  paper  describes  the  semantic  pre- 
processor of  a  TWS.   Semantics  is  specified  as  a  program  written  in  a 
special  purpose  language  called  ISL  which  is  basically  an  extension  of 
ALG0L.  The  extensions  include  some  constructs  often  needed  in  the  de- 
scription of  semantics  of  a  language,  such  as  stack  and  table  declaration 
and  manipulation,  and  control  words  to  automate  to  a  great  extent  the  use 
of  the  TWS.   The  structure  and  use  of  ISL  are  described  and  an  example  of 
the  use  of  ISL  to  specify  the  semantics  of  a  small  subset  of  ALGpL  is 
presented  and  discussed. 
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1.   INTRODUCTION 

The  ILLIAC  IV  array  computer  presently  under  construction  for  the 
University  of  Illinois  employs  an  advanced  concept  of  parallel  design  to  achieve 
a  major  increase  in  processing  capacity.   Obviously,  in  order  to  use  such  capac- 
ity efficiently,  new  procedure  oriented  languages  must  be  developed  to  enable 
the  user  to  take  advantage  of  the  parallelism  of  the  system.   As  these  languages 
are  implemented  it  is  only  natural  to  expect  that  numerous  modifications  will 
need  to  be  implemented  as  users  become  more  experienced  in  the  formulation  of 
algorithms  for  an  array  computer.   It  would  slLso  be  highly  desirable  that  the 
users  themselves  have  access  to  convenient  methods  of  introducing  small  modifica- 
tions in  the  basic  languages  so  as  to  make  them  more  suitable  for  a  particular 
application.   All  these  considerations  pointed  to  a  Translator  Writing  System 
(TWS)  as  a  veiy  convenient  tool  for  achieving  the  objectives  outlined  above. 

As  a  matter  of  convenience,  this  TWS  will  henceforth  be  referred  to  as 
the  ILLIAC  IV  TWS.  This  does  not  imply,  however,  that  the  system  is  only  suitable 
for  generating  compilers  which  produce  ILLIAC  IV  machine  code,  although  this  has 
certainly  been  its  main  use  to  date.   In  fact,  one  of  the  main  features  of  the 
system  is  to  considerably  simplify  the  task  of  producing  a  compiler  for  a  given 
language  L  and  machine  Ml  if  a  compiler  has  already  been  created,  using  the 
system,  for  L  and  another  machine  M2. 

The  ILLIAC  IV  TWS  will  run  on  the  ILLIAC  IV  control  computer,  a 
Burroughs  B-65OO,  and  is  presently  being  used  on  a  Burroughs  B-5500.   The  whole 
system  is  written  in  Burroughs  extended  ALGOL  (henceforth  called  BeA).   The 
reader  is  assumed  to  have  a  basic  knowledge  of  this  language  as  described  in  [l]. 

Briefly,  a  TWS  is  a  system  which,  given  the  complete  description  of  a 
programming  language  (i.e.,  its  syntax  and  semantics)  is  capable  of  producing  a 
compiler  for  that  language.   It  is  well  known  that  a  TWS  can,  in  general,  be 
"divided  into  two  parts: 


a)  A  system,  called  the  Sp-itax  Preprocessor,  which  receives  the  for- 
mal syntactic  description  of  a  language  and  produces  a  recognizer 
for  the  well-formed  constructs  of  such  a  language; 

b)  A  system,  called  the  Semantics  Preprocessor,  which  receives  the 
formal  semantic  description  of  a  language  and  produces  routines 
capable  of  generating  the  appropriate  code  for  each  valid  con- 
struct in  the  language  and  of  building  descriptor  tables. 

As  a  result  of  this  scheme,  the  compilers  produced  by  IWS's  can  also  be  consid- 
ered as  composed  of  two  parts: 

a)  the  syntactic  recognizer; 

b)  the  semantic  routines  which  describe  data  descriptor  manipulation 
and  code  generation. 

Obviously,  there  must  be  connections  between  these  two  parts;  such  connections 
receive  the  name  of  syntax-semantics  links.  Frequently  the  main  syntax-semantics 
link  consists  of  calls,  in  the  syntactic  recognizer,  to  appropriate  routines  in 
the  package  of  semantic  routines.   Therefore,  whenever  a  construct  is  accepted 
by  the  recognizer,  a  certain  set  of  semantic  routines  (or  semantic  algorithms) 
is  executed  in  order  to 

a)  produce  code  corresponding  to  the  construct  recognized,  and/or 

b)  do  some  housekeeping  in  the  tables  and  stacks  that  keep  track  of 
what  has  been  done  so  far. 

Then  the  recognizer  takes  over  again.   Figure  1  illustrates  the  structure  of  the 

"classical"  TWS  outlined  above. 

This  paper  is  devoted  to  the  description  of  the  semantics  preprocessor 

of  the  ILLIAC  IV  TWS  and  its  input,  i.e.,  the  semantic  description  it  accepts. 

The  syntax  preprocessor  is  described  by  Beals  [2]  and  the  syntactic  input  by 

Mercer  [3].   The  system  as  a  whole  will  be  described  by  Machado  and  Northcote[4] 

Some  general  considerations  about  the  syntax  and  semantics  of  a  pro- 
grajnming  language  are  in  order.   The  following  definitions  have  been  presented: 
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source  program  in  L 
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preprocessor 
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syntactic 
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Figure  1.   Classical  structure  of  a  IWS, 
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Syntax:   "The  syntax  of  a  language  is  the  study  of  its  symibols  and 
words  per  se.   It  is  concerned  with  the  struct\ire  of  the 
well  formed  strings  in  the  language  and  with  the  processes 
used  for  generating  or  recognizing  such  strings.  " 
Semantics:   "Semantics  involves  the  assignment  of  meaning  to  the  recog- 
nized syntactic  constructs  through  the  generation  of  des- 
criptors for  those  constructs  and  the  required  object  (out- 
put) string  of  symbols.  " 

In  ^hort,  it  could  be  said  that  semantics  is  the  part  of  a  language 
associated  with  the  meaning  of  the  constructs  whose  well-formedness  is  checked 
by  the  syntax.   A  good  example  is  provided  by  Naur  [5]  in  section  2.kj   in  which 
the  syntax;  and  semantics  of  an  identifier  are  defined  for  ALGOL-60.   One  immedi- 
ately notices  that  the  syntax  is  described  in  a  formal  notation,  using  Backus 
Naur  Form  (BNF)  productions,  while  the  semantics  is  presented  in  plain  English. 
Since  BNF  is  a  formal  system  to  describe  syntax,  a  syntax  preprocessor  could  be 
written  to  accept  a  BNF  description  of  the  syntax  as  its  input.   This  is  most 
reasonable  since  BNF  productions  describe  syntax  (or  rather  most  of  it)  in  a 
clear,  concise,  and  precise  way.   Several  other  formal  notations,  besides  BNF, 
are  available  to  describe  syntax  and  TWS's  have  been  built  using  those  nota- 
tions as  the  syntactic  language;  for  example,  FPL  (Floyd  productions),  TWINKLE 
(an  extension  of  BNF  used  in  the  ILLIAC  IV  IMS) ^   etc.   The  semantics,  however, 
presents  a  problem.   Obviously  a  description  in  English  such  as  the  one  presented 
in  the  example  mentioned  above  could  not  be  accepted  by  a  IVTS  so  the  need  arises 
for  a  formal  Semantic  Description  (SD)  of  a  programming  language.   It  can  be 
seen  immediately  that  the  problem  of  a  formal  SD  is  much  more  complex  than  the 
syntactic  description  problem.   Syntax  (i.e.,  well-formedness)  can  be  described 
in  itself  so  it  is  possible  to  obtain  a  self-contained  syntactic  description. 
Semantics,  on  the  other  hand, is  typically  non-self-contained  since  it  is  related 


with  the  relations  between  the  cc  istructs  of  a  language  and  the  constructs  in 
other  languages  or  entities  in  the  real  world.   It  is  only  possible  to  describe 
the  meaning  of  something  as  a  function  of  the  meaning (s)  of  something  else,  so 
a  set  of  primitive  concepts  or  meanings  must  be  postulated. 

In  the  search  for  a  good  formal  SD  system,  the  following  goals  should 
be  considered. 

1)  The  SD  must  be  simple  enough  to  be  conveniently  utilized  by  the 
users  of  the  TWS. 

2)  The  SD  should  lead  (directly,  or  through  automatic  transformation) 
to  the  generation  of  an  efficient  compiler. 

3)  It  should  lend  itself  to  some  type  of  syntax- semantics  link. 

k)      If  possible,  it  should  be  clear  enough  to  be  practically  used  to 
describe  semantics,  replacing  the  English  descriptions. 

Most  of  the  formal  systems  for  SD  mentioned  by  Feldman  and  Gries  [6] 
were  reviewed  and  considered.   Generally,  SD's  can  be  classified  into  two  large 
groups:  highly  formal  SD's  and  brute-force  SD's.   HighJ.y  formal  SD's  were  basi- 
cally developed  for  one  of  two  purposes:  precise  specification  of  a  programming 
language,  avoiding  the  ambiguities  of  English,  and  for  studying  formal  properties 
of  programs  such  as  equivalence  of  two  programs.   Examples  of  such  highly  formal 
SD's  are:   'Verification  conditions"  as  used  by  Floyd  [7]^  Church's  X  notation 
used  by  Landin  [8],  and  the  program  schemata  introduced  by  lanov  and  discussed 
by  Rutledge  [9].   A  highly  formal  SD  would  appear,  a  priori,  to  be  the  most  con- 
venient notation  to  describe  semantics  in  a  TWS  since  they  are  the  counterpart 
of  BEF,  FPL  and  other  highly  formal  syntactic  descriptions  successfully  used  in 
such  systems.   There  is  one  crucial  problem,  however;  goal  number  2  above  is 
presently  impossible  to  attain  with  a  highly  formal  SD.   Since  those  approaches 
describe  semantics  basically  using  recursion  over  a  smsLLl  set  of  primitive  con- 
cepts whose  meaning  have  been  postulated,  they  tend  to  generate  compilers  that 
would  mimic  this  representation,  i.e.,  the  power  of  a  modern  digital  computer 
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■would  be  wasted  slimilating  a  great  nuraber  of  very  elementary  steps  while  the 
same  computation  could  be  performed  using  a  few  of  the  more  sophisticated  in- 
structions available.   Since  the  ILLIAC  IV  TWS  is  to  be  used  to  generate  prac- 
tical;,  operational  compilers,  efficiency  is  of  paramount  importance  and  the 
approach  of  picking  a  highly  formal  SD  was  abandoned. 

This  left,  as  an  alternative,  the  use  of  a  brute-force  SD.   This  name 
refers  to  the  fact  that,  in  those  SD's,  the  user  himself  must  implement  the 
semantics  of  the  language  by  writing  a  package  of  semantic  routines  using  a 
programming  language.   Such  a  language,  called  the  semantic  metalanguage,  can 
either  be  a  general  purpose  language  like  ALGOL,  or  a  special  language  providing 
features  to  make  the  programming  task  somewhat  easier.   To  this  date  most  WS's 
have  adopted  this  kind  of  solution  to  the  SD  problem.   The  resulting  compilers 
can  be  made  reasonably  efficient,  depending  on  the  ingenuity  of  the  programmer 
writing  the  SD  of  the  language. 

A  review  of  the  existing  systems,  including  systems  that  use  a  general 
purpose  language  as  the  semantic  metalanguage  (Booker  and  Morris  [l?]^  Trout 
[15], [16])  and  the  ones  that  use  a  special  purpose  metalanguage  (Feldman  [lO], 
Northcote  [11],  [l^],  Iturriaga,  e_t.  al.  [12],  [13])^  was  carried  out.  With 
this  background,  it  was  decided  to  implement  a  special  purpose  semantic  meta- 
language for  the  ILLIAC  IV  TWS.   This  language,  called  ISL  (for  Illinois  Semantic 
Language),  is  basically  an  extension  of  ALGOL.   The  extensions  include  some  con- 
structs often  needed  in  the  description  of  semantics,  such  as  stack  and  table 
declaration  and  manipulation.  Most  of  these  constructs  were  suggested  by 
Feldman's  FSL  (Formal  Semantic  Language)  as  described  in  [lO].   The  extensions 
also  include  control  words  to  automate  the  use  of  the  IWS  to  a  significant  extent 

This  approach  seems  to  attain,  within  reasonable  compromise,  the  four 
goals  previously  set  forth.   ISL,  although  a  brute-force  language,  provides  a 
relatively  simple  way  for  an  experienced  ALGOL  programmer  to  describe  semantics. 
Good  efficiency  can  be  obtained  although  this  burden  is  mainly  left  to  the  user. 
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There  are  some  very  convenient  fc^rms  of  syntax- semantics  link.  Finally,  despite 
the  fact  that  it  cannot  completely  replace  an  English  description,  a  profusely 
commented  ISL  program  can  be  a  surprisingly  clear,  concise  and  precise  semantic 
description  for  a  user  familiar  with  ISL. 

An  outline  of  the  remainder  of  the  paper  follows.   In  Chapter  2  aji 
overall  description  of  the  ILLIAC  IV  TWS  is  presented  and  is  a  background  to  the 
sequel.   Chapters  3?   ^  and  5  discuss  the  ISL  implementation,  give  an  informal 
description  of  ISL,  and  give  details  about  the  use  of  the  ISL  translator.   The 
formal  syntax  of  ISL  can  be  found  in  Appendix  A.   Finally,  Chapter  6  presents 
some  general  guidelines  about  describing  semantics  using  ISL  and  a  detailed  dis- 
cussion of  an  example:   the  ISL  semantic  description  of  DEMALGOL  I,  a  small  sub- 
set of  ALGOL.   The  listings  relative  to  this  example  are  found  in  the  remaining 
appendices. 

For  the  reader  who  is  not  interested  in  details  of  implementation 
or  use  of  the  system,  it  is  recommended  that  chapters  2,  k   and  6  only  be  read. 
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2.      TEiE  STRUCIU.IE  OF  THE  TWS 


} 


This  chapter  describes  the  ILLIAC  IV  TWS.   It  is  not,  however,  a 
manual  for  using  the  system  since  no  details  are  given  about  how  to  actually 
run  each  program  of  the  system.   Such  information,  along  with  examples,  can  be 
found  in  [k].      The  purpose  of  this  chapter  is  simply  to  provide  an  understanding 
of  the  system  as  a  whole  since  this  background  is  needed  in  the  discussion  of 
some  ISL  constructs. 

2.1  Basic  Characteristics 

The  ILLIAC  IV  TWS  is  basically  an  implementation  of  the  system  proposed  ; 
by  Northcote  [1^].   Its  main  feature  is  the  use  of  an  intermediate  language  (IL) 
and  multi-pass  compilers.   Although  the  system  can  also  be  easily  used  to  gener- 
ate one-pass  compilers,  its  ability  to  generate  multi-pass  compilers  is  of 
primary  importance  in  achieving  conversion  from  one  machine  to  another  with  a 
minimum  of  effort. 

In  a  multi-pass  compiler,  the  first  pass  translates  the  source  program  ■ 
into  IL  code.   The  following  passes  use  IL  as  both  input  and  output  so  they 
merely  transform  the  IL  string.   The  final  pass  receives  the  last  IL  code  string 
and  outputs  machine  (or  assembly)  code.   The  IL  code  is  syntactically  very  simple 
and  can  be  parsed  very  easily.   The  basic  number  of  passes  for  a  compiler  in  this 
system  is  2:  the  first  pass  transforms  source  language  into  IL  and  the  second 
pass  translates  IL  into  machine  code.   Therefore,  the  first  pass  is  machine 
independent  and  the  second  pass  is  language  independent,  which  allows  the  pro- 
duction of  m  X  n  compilers  (for  m  different  languages  and  n  different  machines) 
by  writing  m  passes  1  and  n  passes  2  instead  of  m  X  n  one-pass  compilers. 

This  basic  2-pass  structure  can  be  modified  by  adding  intermediate 
passes  between  the  first  and  last  passes.   Typically,  intermediate  passes  will 
be  optimization  routines  to  transform  the  IL  string  into  a  more  efficient 


ordering.  Since  these  optimizat:  ons  might  vary  with  the  original  source  language 
and  the  destination  machine,  one  can  envision  as  a  practical  application  a  ^-pass 
compiler  in  which  pass  2  would  perform  a  language -dependent  optimization  and  pass 
3  a  machine -dependent  one. 

2.1.1  Basic  Block  Diagram 

Fig-ure  2  illustrates  the  general  structure  of  the  ILLIAC  IV  IWS. 
Since  the  intermediate  language  has  a  fixed  syntax,  the  IL  recognizer  does  not 
have  to  be  created  for  each  language  and  it  is  simply  an  invariant  package  of 
proced-ures  that  is  inserted  only  once  in  a  multi-pass  compiler  and  is  shared  by 
all  passes  after  the  first  one.   It  should  also  be  noted  that  Figure  2  presents 
only  the  principles  of  the  system  in  a  simplified  way.   Section  2.3  discusses 
the  details  of  the  actual  implementation. 

2.1.2  The  Intermediate  Language 

The  concept  of  multi-pass  compilers  with  an  IL  works  very  well  until 
it  becomes  necessary  to  define  the  operators  in  the  IL.   Then  limitations  and 
particularizations  are  practically  inevitable  and,  when  a  new  language  or  a  new 
machine  is  being  introduced  in  the  system,  one  realizes  that  he  needs  a  few  more 
IL  instructions  to  cope  with  some  special  features.   In  order  to  avoid  this  prob- 
lem in  the  ILLIAC  TV  TWS,  the  IL  is  not  fixed  in  content,  i.e.,  it  does  not  have 
a  closed  repertoire  of  instructions.  What  is  fixed  about  the  IL  is  its  struc- 
ture.  In  fact,  the  syntax  of  the  IL  can  be  defined  simply  as  follows: 

<IL  program>  : :  =  <IL  operand>  |  <IL  operator>  |  <IL  program>  <IL  operand>  | 

<IL  program>  <IL  operator> 

Thus  an  IL  program  is  simply  a  string  of  elements,  each  of  which  is 
either  an  operator  or  an  operand.   Each  IL  element  is  basically  a  pair  of 
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Figure  2.   General  structure  of  the  ILLIAC  IV  IWS. 
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integers,  the  first  integer  is  called  the  '4:able  number"  and  the  second  the 
"entry".  Any  element  with  a  non-zero  table  number  is  an  operand;  a  table  num- 
ber equal  to  zero  designates  an  operator.   All  the  IL  recognizer  has  to  do  to 
'^arse"  an  element  of  the  IL  is  to  check  the  table  number.   If  the  table  number 
is  non-zero,  the  whole  element  is  pushed  into  a  stack;  if  the  table  number  is 
zero,  the  semantic  routine  whose  number  is  equal  to  the  entry  in  that  element 
is  executed.   Figure  3  is  a  block  diagram  of  the  IL  recognizer.   It  is  obvious 
that  the  IL  string  may,  in  fact,  be  Polish  postfix  notation  and  a  semantic  rou- 
tine can  pick  its  parameters,  if  any,  by  popping  the  stack.   The  fact  that  the 
set  of  operators  is  not  fixed  justifies  calling  such  a  language  a  "generalized 
intermediate  language". 
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Figure  3.   Block  diagram  of  the  IL  recognizer. 
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Thus^  pass  i  (i  >  l)  semantics  is  implL.emented  with  a  modular  approach;  in  a  way, 
the  user  can  add  whatever  operators  he  needs  in  the  IL  as  soon  as  he  also  writes 
a  semantic  routine  (i.e.,  an  ISL  procedure  or  block  of  code)  specifying  the  new 
operator.   This  semantic  routine  will  then  be  present  in  pass  i  and  the  new 
operator  becomes  available  in  the  IL  at  that  pass.   After  the  first  few  compilers 
are  written  for  a  given  machine  M,  there  will  be  a  good  library  of  IL  operators 
available  along  with  the  semantic  routines  defining  them.   The  user  will  seldom 
have  to  define  new  IL  operators  as  he  will  probably  be  able  to  describe  his 
semantics  using  the  operators  already  present  in  the  library.   However,  he  does 
have  the  possibility  of  adding  new  operators  when  they  are  needed  to  allow  good 
efficiency  of  the  generated  code. 

To  give  to  the  user  the  freedom  (and,  unfortunately,  the  burden)  of 
defining  his  own  IL  operators  means,  in  fact,  that  he  has  to  decide  how  to 
divide  his  description  of  a  language  into  passes.   Considering  the  case  of  a 
2-pass  compiler,  the  user  might  either  have  pass  1  do  almost  all  work  and  pass  2  ' 
would  be  a  trivial  emitter  of  machine  code,  or  he  could  leave  practically  every- 
thing to  be  done  in  pass  2,  pass  1  being  only  to  recognize  syntax  and  emit  post-  ■ 
fix  code.   Obviously,  the  correct  approach  is  a  compromise  in  which  characteris-  ] 
tics  belonging  to  the  language  are  translated  in  pass  1  and  machine  features  are  ■, 
dealt  with  in  pass  2.   It  is  interesting  to  note,  however,  that  pass  1  should 
fragment  the  input  program  into  instructions  not  sinipler  than  the  instructions 
available  in  the  machines  for  which  a  pass  2  will  be  written.   For  instance,  if 
pass  1  translates  the  statement  A©  B  (where  ©  means  exclusive  or)  into  the 
following  intermediate  code:  A,  NOT,  B,  AND,  A,  B,  NOT,  AND,  OR,  then  every 
machine  will  execute  the  statement  in  this  way,  which  is  inefficient  for  a 
machine  that  has  an  exclusive  or  instruction  in  its  repertoire.   These  considera- 
tions about  where  to  divide  a  compiler  between  passes  have  to  be  loose,  since 
only  general  guidelines  may  be  given.   It  is  hoped  that  the  example  in  Chapter  6 
will  provide  some  additional  insight  with  respect  to  this  problem. 


2 . 2  The  Structure  of  Translators  fenerated  by  the  System 

The  right  hand  side  part  of  Figiore  2  contains  a  simplified  block 
diagram  of  a  translator  generated  by  the  ILLIAC  IV  TWS.   Each  pass  is  basically 
composed  of  a  syntactic  recognizer  and  a  package  of  semantic  routines.   The 
format  of  each  package  is  essentially  the  same  for  every  pass.   The  syntactic 
recognizer^  however,  is  completely  different  for  pass  1  and  for  the  subsequent 
passes.   All  passes  i  (i  >  l)  use  the  same  IL  recognizer,  which  is  quite  simple. 
Pass  1,  however,  needs  a  very  elaborate  parser  and  scanner  in  the  syntactic  rec- 
ognizer.  For  this  reason,  the  case  of  a  one-pass  compiler  will  be  studied  sep- 
arately with  its  syntactic  recognizer  described  in  detail.   Then  the  more  complex 
multi-pass  compilers  can  be  explained  without  further  comments  about  their  first 
passes.   It  should  also  be  noticed  that  the  primary  output  produced  by  the  IWS 
system  is  not  a  final  compiler  but  a  BeA  program,  i.e.,  the  compiler  in  source 
code  form.   The  ALGOL  compiler  is  then  used  to  "compile  the  compiler"  and  the 
resulting  machine  code  is  the  final  compiler.   Therefore,  discussion  of  the  com- 
pilers generated  will  be  in  terms  of  such  compilers  as  ALGOL  programs.   Reference 
to  the  ALGOL  block  structure  of  the  compilers  will  be  made  quite  often  to  clarify 
the  scope  of  each  procedure  or  table  in  the  compiler. 

2.2.1  One -pass  Compilers 

Figure  k   presents  a  simplified  ALGOL  block  structure  of  a  one -pass 
compiler  generated  by  the  ILLIAC  IV  TWS.   The  main  components  of  the  syntactic 
recognizer  are  two  packages  of  declarations:  the  SCADiTNER  package  and  the  PARSER 
package.   Between  those  two  groups  of  declarations  there  is  a  single  executable 
statement:  a  call  to  procedure  INITIALIZE  whose  basic  role  is  to  fill  the  scan- 
ner tables  (the  scanner  is  table -driven).   For  reasons  that  will  become  apparent 
in  section  2.2.2,  a  block  of  declarations  is  detached  from  the  SCAKNER  package 
and  placed  at  the  very  beginning  of  the  program.   It  is  called  the  GLOBAL  package; 
among  its  contents  are:  MMERRS,  which  contains  the  number  of  errors  detected 
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Figure  k.      ALGOL  block  structure  of  a  one-pass  compiler. 


15 

'  during  compilation;  CAEIDCOIINT,  which  contains  the  nimiber  of  cards  compiled; 
CARDNUM,  which  contains  the  niomber  of  the  sequence  field  (columns  73-8o)  of  the 
card  presently  being  compiled;  STACKSIZE,  which  contains  the  number  of  locations 
desired  in  the  main  syntactic  recognition  stack.   The  fact  that  these  four  quan- 
tities are  always  the  first  four  declarations  in  a  compiler  allows  them  to  be 
easily  monitored  with  console  commands  whenever  the  compiler  is  running  in  a 
B-5500.   Following  the  PARSER  comes  the  SEMANTICS  package  which  contains  the 
declarations  of  the  semantic  variables  and  routines.   Finally,  there  are  a  few 
executable  statements.   The  most  important  of  these  is  a  call  to  procedure  PARSE 
which  results  in  compilation  of  the  source  program.   Then  procedure  PEKD  (for 
parser  end)  is  executed  to  get  some  statistics  about  the  compilation  and  the  exe- 
cution of  the  compiler  is  terminated.   Each  block  will  now  be  analyzed  in  more 
detail. 

2.2.1.1  The  Scanner  and  BIGTAB 

The  main  procedure  in  the  SCAJMER  package  is  an  alpha  procedure  called 
SCAN.   Each  time  the  parser  needs  another  element  from  the  input  string  (source 
program),  it  calls  SCAN  which  scans  the  input  and  returns  the  next  element;  it 
includes  the  reading  of  new  cards  as  necessary.   An  updated  version  of  the  scan- 
ner, to  be  described  by  Balier,  will  be  inserted  in  the  system  as  soon  as  it  is 
operational. 

The  scanner  recognizes  basically  four  types  of  elements,  each  desig- 
nated by  a  type  number: 

type  1  :  Identifiers  (as  defined  in  [l],  pages  2-5) 

type  2  :  Numbers  (as  defined  in  [l],  pages  2-6) 

type  3  :  Strings  (as  defined  in  [l],  pages  2-7) 

type  15:  Terminal  symbols.   These  can  appear  in  three  different  forms: 
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a)  Single  characters. 

Example :  *-   (the  single  character  left  arrow) 

b)  Reserved  words.   These  are  identifiers  that  appear  as  terminal 
symbols  in  the  syntactic  definition  of  the  language;  the  scanner 
distinguishes  them  from  coimnon  identifiers. 

Example:   BEGIN  (in  ALGOL) 

c)  Special  words.   This  is  a  special  mode  in  which  the  user  must 
immediately  precede  all  identifiers  which  are  terminals  with  a 
special  character  (usually  #). 

Example:  #BEGIN  (in  ALGOL) 
Since  all  terminal  identifiers  are  identified  by  the  special  pre- 
fix, the  same  identifier  could  appear  without  the  prefix  and  would 
be  considered  a  valid  identifier.   This  is  one  advantage  of  the 
special  word  option.   Another  is  the  fact  that  scanning  identifiers 
is  somewhat  faster,  since  all  the  reservedwords  do  not  have  to 
be  matched  against  each  identifier  as  happens  in  the  reserved  word  ; 
option.   The  obvious  disadvantage  is  the  use  of  the  prefix  before 
each  terminal  identifier.   The  same  compiler  can  be  used  either 
with  reserved  words  or  with  special  words,  dependent  on  a  control 
card  option  introduced  at  compile  time. 

The  unallocated  symbol  type  numbers  may  be  utilized  by  the  user  to' 
define  additional  symbol  types  for  his  language. 

As  the  scanner  first  recognizes  identifiers,  strings  and  numbers, 
they" are  entered  in  a  table  called  BIGTAB.  When  any  of  these  elements  appears 
a  second  time  the  address  of  the  previous  entry  is  returned.   BIGTAB  is  a  linear 
table  of  about  80OO  US-bit  words.   Each  word  in  BIGTAB  can  be  one  of  three  types: 
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a)  heading  word; 

b)  character  word; 

c)  ntimber  word- 

Numbers  are  stored  using  the  standard  B-5500  representation  with  a  mantissa 
and  an  exponent  (which  is  zero  for  integers).   The  formats  of  heading  words 
and  character  words  are  given  in  Figure  5«   Each  set  of  elements  of  the  same 
type  is  entered  in  BIGTAB  according  to  a  binary  tree  structure  with  left  and 
right  pointers  linking  all  its  elements  thus  enabling  the  scanner  to  perform 
fast  table  lookups.   This  structure  allows  several  different  trees  to  be  inter- 
leaved in  BIGTAB,  each  tree  having  a  different  root.   The  first  locations  of 
BIGTAB  are  used  as  follows:  BIGTAB  [i]  (O  <  i  <  15)  contains  a  pointer  to  the 
root  of  the  tree  of  elements  of  type  i.   Thus  BIGTAB  [l]  points  to  the  root  of 
the  tree  of  identifiers.   The  first  location  of  BIGTAB  used  for  an  entry  is  l6 
and  the  locations  are  used  in  increasing  sequence. 

Entries  in  BIGTAB  for  each  type  are  specified  as  follows. 

identifiers:  Each  entry  contains  one  heading  word  and  from  one  to  eight 

character  words  (as  needed)  containing  the  BCD  for  the  identi- 
fier.  Thus  an  identifier  in  this  system  may  be  up  to  kQ 
characters  long.   Figure  6  illustrates  the  entry  of  an  identi- 
fier in  BIGTAB.   Notice  that  the  address  of  an  entry  in  BIGTAB 
is  always  the  address  of  its  heading.   The  number  of  words 
used  per  entry  may  vary  from  2-9.   Unused  characters  in  the 
last  word  of  the  entry  are  filled  with  blanks, 
numbers:  Each  entry  contains  one  heading  word  and  one  number  word  in 
which  the  value  of  the  number  is  stored  in  the  conventional 
B-5500  way.   The  field  SEM  in  this  case  is  set  to  a  number 
that  represents  the  sum  of  all  words  used  so  far  in  entries 
of  numbers  and  strings.   This  is  useful  when  it  is  desired. 
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SEM:   Semantics  field;  reserved  for  use  by  the  semantics 
WORDS:   Contains  n-1  where  n  is  the  nimiber  of  extra  words  (besides  the  head- 
ing) used  for  this  entry 
CHARS:  Contains  the  number  of  characters  in  the  last  word  of  this  entry 
LEFTPT:   Left  pointer;  contains  the  address  of  the  heading  of  the  entry  to  the 
left  of  this  one  in  a  binary  tree  structure 
RIGHTPT:  Right  pointer;  contains  the  address  of  the  heading  of  the  entry  to  the 
right  of  this  one  in  a  binary  tree  structure 

Character  word: 
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Each  field  contains  one  character  in  the  Burroughs  set  of  6U  characters,  accord- 
ing to  the  conventional  integer  assigned  to  each  character  in  Table  1. 


Figure  5.   Format  of  words  in  BIGTAB. 
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FigTire  6.      Sample  entry  of  an  identifier  in  BIGTAB. 
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at  the  end  of  pass  1,  to  extract  all  niamibers  and  string 
entries  out  of  BIGTAB  and  condense  them  in  a  table  of  lit- 
erals to  be  passed  to  pass  2, 
strings:   Are  stored  similarly  to  identifiers,  with  the  limiting  quotes 
removed.   The  SEM  field  is  set  as  described  above  for  numbers. 

special  or 
reserved  words:   Are  stored  similarly  to  identifiers  except  that  in  the  field 

SEM  there  is  a  code  number.   This  number  is  assigned  to  each 
reserved  word  by  the  syntactic  preprocessor.   The  first  re- 
served word  found  is  assigned  the  value  66  and  so  on  in  se- 
quence.  Thus  each  terminal  has  a  number  assigned  to  it:   if 
it  is  a  single  character,  such  number  is  the  character  num- 
ber as  defined  in  Table  1.   If  it  is  a  mult i- character  termi- 
nal, it  has  a  code  number  >  66  assigned  by  the  sjmtactic  pre- 
processor. 

Note  that  the  numbers  6k   and  65  were  left  out.    They  are  used  to 
indicate  "end-of-file"  and  "illegal  terminal", respectively.   End-of-file  is  the 
terminal  returned  when  there  are  no  more  elements  to  be  read  in  the  input  string.' 
Illegal  terminal  is  returned  when,  under  special  word  option,  a  special  word  is  ■ 
found  which  had  not  been  defined  in  the  syntactic  specifications.  Under  the 
special  word  option  there  are,  in  general,  four  trees  in  BIGTAB:   identifiers, 
numbers,  strings  and  special  words.  Under  reserved  words,  however,  the  tree  of 
special  words  does  not  appear  as  an  independent  tree  but  as  the  initial  part  of 
the  identifier  tree.   If  an  "identifier"  falls  within  this  initial  part  it  is, 
in  reality,  a  reserved  word;  otherwise  it  is  a  proper  identifier. 

Whenever  the  scanner  is  called,  it  returns  essentially  a  pair  of  inte- 
gers:  (n,m)  where  n  is  the  type  and  m  is  the  entry.   In  all  cases,  n  will  be 
the  type  of  the  element  scanned  (i.e.,  1,  2,  3,  or  15  accordingly  as  the  element 
scanned  was  an  identifier,  etc.).   The  setting  of  m  depends  on  the  type.  For 
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TABLE  1 
SET  OF  CHARACTERS  WITH  THEIR  INTERNAL  NUMBERS 
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V 

^ 

a 

(U 

cS 

0) 

03 

<u 

a 

0 

^ 

^ 

^ 

,g 

^ 

,l 

^ 

,Q 

^ 

p 

Xi 

3 

^ 

p 

Xi 
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SU 

o 

fl 
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fl 

o 

C! 
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0 
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16 

X 

a 

32 

X 

4  8 

1 

8 

1 

A 
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17 
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a 

33 
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a 

49 

? 

3 

2 

B 

X 

18 

K 

a 

34 

S 

a 

50 

3 

S 

3 

C 

X 

19 

L 

z 

35 

T 

X 

51 

4 

S 

4 

D 

X 

20 

M 

a 

36 

U 

= 

52 

5 

S 

5 

E 

X 

21 

N 

a 

37 

V 

X 

53 

ft 

X 

6 

F 

B 

22 

0 

a 

38 
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X 

54 

7 

r 

7 

G 

B 

23 

P 

X 

39 

X 

X 

55 

R 

B 

8 

H 

S 

24 

Q 

a 

40 

V 

X 

56 

Q 

s 

9 
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X 

25 

R 

X 

41 

z 

B 

57 

f 

s 

to 

• 

X 

26 

$ 

a 

42 

f 

X 

58 

a 

= 

tl 
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X 

27 

* 

a 

43 

% 

B 

59 

? 

s 

12 
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3 

28 

- 

a 

44 

4 

X 

60 
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s 

13 
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S 

29 

) 
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45 

X 

X 
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\H 
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30 

t 

a 

46 
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a 
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> 

B 

15 
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a 

31 
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a 

47 

tt 

a 

63 
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any  type  not  equal  to  13,   m  is  the  adojress  of  the  entry  of  the  element  in 
BIGTAB.   For  type  15,  m  is  the  code  number  associated  with  the  terminal,  as 
explained  previously. 

To  complete  the  description  of  the  scanner  it  is  necessary  to  describe 
the  special  meaning  of  the  characters  '%"  and  "$".   The  character  '^",  when  not 
embedded  in  a  string,  terminates  the  reading  of  a  card  causing  all  the  remain- 
ing characters  in  that  card  to  be  ignored.   The  character  "$",  when  in  column  1 
of  the  card  and  not  embedded  in  a  string,  causes  the  card  to  be  interpreted  as  a 
control  card.   The  card  is  expected  to  contain  a  string  of  control  words  sepa- 
rated by  blanks;  the  string  must  be  terminated  by  a  semicolon  ("j")«   Table  2 
presents  a  list  of  the  available  control  words  and  their  effect.   For  certain 
applications,  the  user  may  desire  to  add  some  control  words  of  his  own,  besides 
the  ones  provided  by  the  system.   One  of  the  procedures  in  the  SCANKER  package, 
LANGUAGECONTROLCAED,  allows  this  facility.   The  user  is  expected,  in  this  case, 
to  write  his  own  procedure  LANGUAGECONTROLCARD  to  accept  the  additional  options 
and  insert  it  in  place  of  the  original  procedure,  which  is  simply  a  marker  and 
has  no  action  whatsoever. 

The  way  the  scanner  treats  blanks  and  the  way  it  recognizes  multi- 
character elements  can  also  be  modified  to  a  great  extent  by  setting  certain 
variables  to  the  appropriate  values.   Table  3  presents  the  complete  list  of  such 
scanner  control  variables  and  their  effect.   There  is,  however,  one  important 
restriction  in  the  use  of  these  variables:  when  a  semantic  routine  modifies  a 
scanner  control  variable,  one  must  be  sure  that  the  element  which  must  be  scanned 
under  the  new  mode  has  not  been  scanned  yet.   Such  could  be  the  case  if  look- 
ahead  is  needed  at  that  point  in  the  parsing. 


i 


23 


T/3LE  2 
DOLLAR  CAEID  CONTROL  WORDS  MD   THEIR  EFEECT 


obs 


AFFECTS 


EFFECT 


must  be  fol- 
lowed by  a 
special  char- 
acter:  c 

must  be  fol- 
lowed by  an 
unsigned  in- 
teger: n 


NOSTACKLIST 


scanner 


scanner 


scanner 


scanner 


parser 


parser 

parser 
parser 

parser 
parser 

parser 
parser 

parser 
parser 

parser 


Prints  the  source  cards  on  the  line  printer 
as  they  are  needed.   (default) 


Turns  off  option  above, 


Uses  reserved  words. 


Uses  special  words  marked  by  the  prefix  c 
(default  with  c  =  "#"). 


Uses  a  parsing  stack  n  words  long  (default 
n  =  100). 


Requests  all  deb\;igging  aids  available;  is 
equivalent  to  setting  the  next  six  options. 


Turns  off  option  above  (default). 

Prints  message  as  each  semantic  routine  is 
called  for  execution. 


Turns  off  option  above  (defaxilt). 

Prints  message  when  the  parser  starts  to 
look  for  each  specific  non-terminal. 

Turns  off  option  above  (default). 

Prints  message  when  the  parser  finds  the  non- 
terminal it  was  looking  for. 

Turns  off  option  above  (default). 

Prints  the  situation  of  the  stack  (up  to  the 
top  ten  symbols  only)  as  each  terminal  is 
pushed  into  it. 

Turns  off  option  above  (default). 


2k 


TABIE  2 
(CONTINUED) 


COWTKOL 
WORD 

Obs 

AFFECTS 

EFFECT 

PARSER 

parser 

Prints  the  number  of  the  first  FP  in  a 
group  as  each  new  group  of  FP's  is  ini- 
tiated. 

NOPARSER 

parser 

Turns  off  option  above  (default). 

SCAN 

scanner 

Prints  message  as  each  source  program 
element  is  scanned. 

NOSCAN 

scanner 

Turns  off  option  above  (default). 

TIMES 

PEND 

At  the  end  of  the  compilation,  prints  times 
spent  in  each  activity  (scanning,  parsing, 
etc. ). 

ILCARD 

IL 

Outputs  in  the  IL  string  information  about 
the  card  number  each  time  a  new  card  is 
read. 

ILLIST 

IL 

Starts  printing  the  IL  string  as  it  is  read 
by  pass  2;   this  automatically  turns  on  the 
option  above. 

NOILLIST 

IL 

Turns  off  option  above  (default). 

*     These  options  are  valid  only  when  input  before  the  first  non-control  card 
in  the  source  deck. 
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TABLE  3 
SCMNER  CONTROL  VARIABLES  AND   THEIR  EFFECT 


VARIABLE 


TYPE 


INITIALIZED 
TO 


VALUE 


EFFECT 


SCANMODE 


INTEGER 


Recognizes  all  types  of  elements 
(id's^  numbers,  strings,  etc.); 
blanks  are  completely  ignored. 

Same  as  0  except  blanks  are  recog- 
nized; multiple  blanks  are  reduced 
to  a  single  blank. 

Does  not  recognize  ids,  etc.  as 
as  such  but  as  a  string  of  single 
characters.   Blanks  are  ignored. 

Same  as  2  except  blanks  are  also 
returned;  multiple  blanks  are  re- 
duced to  a  single  blank. 

Same  as  0  but  does  not  make  any 
entry  in  BIGTAB. 

Same  as  3  but  multiple  blanks  are 
not  reduced  to  a  single  blank. 


FRSTCOL 


LAS TOOL 


INTEGER 


INTEGER 


72 


LETTERCHAR    BOOLEAN     FALSE 


DIGITCHAR     BOOIEAN     FALSE 


STRINGCHAR    BOOLEAN     FALSE 


SPECIALCHAR   BOOLEAN     FALSE 


Starts  reading  each  card  at 
column  i. 

Stops  reading  each  card  after 
column  i. 

If  true,  recognizes  identifiers 
character  by  character. 

If  true,  recognizes  numbers  char- 
acter by  character. 

If  true,  recognizes  strings  char- 
acter by  character. 

If  true,  recognizes  special  words 
character  by  character. 


conditional  oh  the  setting  of  the  four  boolean  variables:  LETTERCHAR,  DIGITCHAR, 
STRINCHAR  and  SPECIALCHAR 
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2.2.1.2  The  Parser  and  MSTACK 


The  PARSER  package  contains  all  the  procedures  that  actually  parse 
the  Input  string  of  source  code.   Since  the  final  result  of  the  syntactic  pre- 
processor is  a  deterministic  set  of  Floyd  Productions  (FP's)  describing  the 
syntax,  the  task  of  the  PARSER  procedures  is  to  apply  those  productions  to  the 
source  string.   This  is  done  "by  the  FP  package.  Also  important  are  the  proce- 
dures LK,  "which  does  the  lookahead,  and  FILLTAB,  which  is  executed  at  the  begin- 
ning of  the  compilation  and  initializes  several  tables,  among  them  BIGTAB  with 
the  reserved  words.   The  parser  uses  a  stack  called  MSTACK  whose  word  format  is 
illustrated  in  Figure  7.   MSTACK  contains  a  number  of  J+8-bit  words  equal  to  the 
value  of  STACKSIZE.   This  number  can  be  set  with  a  control  option  (see  Table  2); 
the  default  size  is  100. 

As  the  elements  of  the  source  string  are  scanned,  they  are  pushed  into 
MSTACK  as  described  in  Figure  7*   When  the  contents  of  the  top  n  locations  of 
MSTACK  matches  the  n-symbol  right-hand  side  of  a  production,  the  parser  may  de- 
cide (depending  perhaps  on  the  lookahead  situation)  to  effect  a  reduction.   The 
reduction  then  consists  of  discarding  the  top  n-1  symbols  in  MSTACK.   The  n-th 
symbol,  now  top  of  MSTACK,  is  associated  with  the  nonterminal  on  the  left  hand 
side  of  the  production  which  was  applied.   Note  that  this  association  is  only 
internal,  however,  and  physically  the  contents  of  MSTACK  remain  as  they  were. 

Example:   Assume  that  MSTACK  is:   ...  #G0   #T0|  (the  vertical  bar 
is  used  to  indicate  the  top  of  the  stack)  and  that  the  BNF  production: 
<G0  TO  SYMBOL>  ::=  #G0  ^0   will  be  applied.   The  position  of  MSTACK  containing 
the  #T0  is  erased  and  all  information  stored  in  it  is  lost.   The  top  of  MSTACK 
is  now  associated  with  the  nonterminal  <G0  TO  SYMB0L>  but  the  contents  of  the 
top  of  MSTACK  continues  to  be:   (type  15,  entry  =  number  associated  with  the 
terminal  #G0).   Technically,  one  could  say  that  the  actual  contents  of  a  position 
of  MSTACK  associated  with  a  nonterminal  are  the  leftmost  terminal  of  the  string  of 
terminals  that  were  reduced  to  that  nonterminal. 
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MSTACK  word: 
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-^    LTYPE 


it 


6  :  12 


ENTRY 
18  :  12 


TYPE 
30  :  6 


ILENTRY 
36  :  12 


0 


18 


30 


36 


^7 


LTYPE:   In  pass  1,  contains  a  copy  of  the  five  rightmost  bits  of  the  TYPE 
field;  in  pass  i  (i  >  l),  this  field  can  be  used  for  semantics. 

SEM:  Semantics  field,  reserved  for  use  by  the  semantics.  In  pass  1, 
when  the  result  of  a  scan  is  placed  in  MSTACK,  the  rightmost  12 
bits  of  the  SEM  field  in  BIGTAB  are  automatically  copied  in  the 
SEM  field  of  MSTACK. 

ENTRY:   In  pass  1,  contains  the  nimber  of  the  element,  as  returned  by  the 
scanner;  in  pass  i  (i  >  l),  this  field  can  be  used  for  semantics. 

TTPE:  In  pass  1,  contains  the  type  number  of  the  element,  as  returned  by 
the  scanner;  in  pass  i  (i  >  l),  this  field  contains  the  table  num- 
ber of  an  IL  operand. 

ILENTRY:   In  pass  1,  when  the  result  of  a  scan  is  placed  in  MSTACK,  this 

field  is  initialized  to  zero  unless  the  element  is  a  terminal  in 
which  case  the  code  number  is  entered;  in  pass  1  (i  >  l),  this 
field  contains  the  entry  number  of  an  IL  operand. 


Figure  7-   Format  of  the  words  in  MSTACK. 


28 

2.2.1.3  The  Semantic  Routines 

Much  will  be  said  in  subsequent  chapters  about  the  SEMANTICS  package. 
For  the  time  being,  it  is  only  important  to  note  that  the  main  procedure  of  the 
SEMANTICS  package  is  called  EXEC.   EXEC  has  one  integer  parameter  and  the  result 
of  a  call  on  EXEC  with  parameter  n  is  that  semantic  routine  nuinber  n  (only)  will 
be  executed.   Thus,  when  the  parser  decides  it  is  time  to  execute  semantic  rou- 
tine number  (say)  k3,   all  it  does  is  to  call  EXEC  (^3). 

2.2.2  Multi-pass  Compilers  -  the  IL  Recognizer 

Figure  8  presents  a  simplified  ALGOL  block  structure  of  a  multi-pass 
compiler  generated  by  the  ILLIAC  IV  TWS.   It  should  be  noted  initially  that  the 
GLOBAL  package  has  been  moved  to  the  very  beginning  of  the  compiler.   Therefore, 
the  declarations  it  contains  are  global  to  all  passes  and  may  be  used  by  all. 
Thus  GLOBAL  includes  all  the  declarations  of  elements  that  the  system  must  use 
in  all  passes.   Notice  also  that  STACKSIZE  is  now  global  to  the  whole  program  so 
all  passes  will  use  it  as  the  size  of  their  MSTACK.   Since  all  passes  i  (i  >  l) 
use  the  same  IL  recognizer,  the  procedures  in  the  IL  RECOGNIZER  package  are 
entered  only  once  and  are  accessed  by  all  those  passes.   It  should  also  be  noted 
that  one  more  package  was  introduced:  the  ALGOL-HEAD  package.   It  can  be  con- 
sidered the  user's  counterpart  of  the  GLOBAL  package;  it  contains  the  declarations 
of  all  the  semantic  elements  that  should  be  transferred  between  passes.   Of 
course,  the  main  vehicle  of  transfer  of  information  between  passes  shoiild  be  the 
IL  string.   However,  it  is  also  very  often  necessary  to  transfer  some  tables  and 
stacks  to  which  IL  operands  point.   In  fact,  due  to  the  small  size  (l6  bits)  of 
an  intermediate  language  operand,  unless  the  language  being  implemented  is  quite 
simple,  such  operands  cannot  contain  the  whole  information  to  be  communicated  be- 
tween passes.   It  is  up  to  the  user  to  decide  which  information  he  wants  trans- 
ferred between  passes  and  to  place  the  declarations  of  those  elements  in  HEAD 
instead  of  in  a  particular  SEMANTIC  package.  . 
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BEGIN 


END. 


GLOBAL  package 


ALGOL-HEAD  package 


Pass  1  block  as 
detailed  in  Figiire  k 
but  without  the 
GLOBAL  package. 


BEGIN 


IL  RECOGNIZER  package 


contains  the  proce- 
dures CONTEXT  and 
SKIPIL_, 


BEGIN 


PASS  2  SEMANTICS  package 


Call  IL  RECOGNIZER 


END 


BEGIN 


PASS  n  SEMANTICS  package 


Call  IL  RECOGNIZER 


END 


END 


Figure  8.   ALGOL  block  structure  of  a  multi-pass  compiler. 
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The  IL  structxare  and  its  reoognizer  have  already  been  generally  des- 
cribed in  section  2.1.2.   All  that  is  left  is  to  add  some  ijnplementation  details. 
The  format  of  an  IL  element  is  shown  in  Figure  9.   Foiir  bits  are  reserved  for 
the  table  number  and  12  bits  for  the  entry.   In  this  way,  tht^  IL  elements  can 
be  packed  in  one  B-650O  43-bit  word.   This  is  not  being  done  with  the  B-5500 
because  one  of  the  k&   bits  is  inaccessible  to  the  user.   The  stack  used  by  the 
IL  recognizer  is  also  called  MSTACK  and  the  use  of  each  field  is  described  in 
Figure  7. 


IL  element 


r 


Table 
No. 

Entry 

^                                    ^ 

k  bits 

^ 

12  bits 

w 

Figure  9*   Format  of  an  IL  element. 


Finally,  it  should  be  added  that  although  the  ideal  form  of  the  IL  is 
pure  postfix  notation,  sometimes  it  is  convenient  to  give  the  user  freedom  to 
scan  the  IL  string  from  inside  a  semantic  routine  for  a  lookahead,  a  local  opti- 
mization, or  some  other  trick.   For  this  purpose  two  procedures  are  available: 
CONTEXT  (n)  which  is  typed  integer  and  returns  the  element  in  relative  position 
n  in  the  IL  string  (-30  <  n  <  59)  and  SKIPIL  (n),  a  non -typed  procedure  which 
displaces  the  IL  string  by  n  where  n  is  any  integer.   Two  IL  operators  have  a 
predefined  meaning  for  the  IL  Recognizer.   Operator  number  64  is  the  end-of-file 
transfer.   When  it  is  recognized,  the  Recognizer  stops  and  the  compiler  proceeds 
to  the  next  pass  (if  any).  A  semantic  routine  for  operator  number  65  is  provided 
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by  the  Recognizer  itself.  When  that  operator  appears  in  the  IL  string  it  is 
known  that  the  IL  ENTRY  field  on  top  of  MSTACK  contains  a  card  nimber  and  TYPE 
contains  either  2  (meaning  list  XL)  or  1  (meaning  do  not  list  IL). 

In  the  first  case  the  routine  associated  with  operator  65  prints  a 
card  number  message  on  the  line  printer;  in  the  second  case  nothing  is  done. 
Thus  the  user  may  obtain  at  pass  2  a  listing  of  the  IL  string  being  processed 
along  with  the  numbers  of  the  cards  that  originated  it.   This  capability  is  con- 
trolled by  the  three  control  words  that  affect  IL  (see  Table  2).   Obviously,  the 
user  may  choose  to  supply  his  own  semantic  routine  for  operator  65  if  he  wants 
something  else  done  at  card  boundaries  during  the  reading  of  the  IL  string. 

2.3  The  Actual  System 

This  section  contains  a  detailed  description  of  the  block  structure  of 
the  ILLIAC  TV  TWS  as  it  has  been  actually  implemented.   The  function  of  each 
block  is  briefly  discussed  with  references  to  the  paper  in  which  they  have  been 
fully  described. 

2.3.1  Detailed  Block  Diagram 

Figure  10  presents  the  detailed  block  diagram  of  the  ILLIAC  IV  IWS. 
The  actual  system  is  composed  of  five  major  programs  and  a  TWS  Symbolic  Library 
containing  several  pieces  of  ALGOL  source  code.   In  Figure  10  the  upper  row, 
containing  four  boxes,  corresponds  to  the  syntax  preprocessor.   The  approach  of 
dividing  the  syntax  preprocessor  into  four  programs  presents  two  major  advan- 
tages.  If  the  whole  syntactic  preprocessor  had  been  packed  in  only  one  program, 
the  res"ulting  code  would  be  extremely  large  and  could  not  be  run  efficiently  in 
the  B-5500  due  to  large  overlay  time.   Secondly,  each  of  the  foiir  programs  per- 
forms a  distinct  logical  task.   The  B-5500  system  provides  facilities  for  ini- 
tiating the  execution  (on  a  multiprocessing  basis)  of  one  program  by  means  of 
executing  a  special  statement  in  another  program  being  executed.   Therefore, 
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dividing  the  syntax  preprocessor  does  not  pose  the  disadvantage  of  requiring 
the  user  to  execute  four  programs  instead  of  orHjy   one.   The  user  executes  only 
the  first  program  (the  TWINKLE  Translator)  and  each  program,  just  before  ending, 
initiates  the  execution  of  the  next  one.   In  fact,  it  is  possible  to  input  to  the 
TWINKLE  Translator  both  the  syntactic  and  semantic  description  of  a  language  L 
and  have  the  system,  completely  automatically,  end  up  with  a  compiler  for  L  (in 
executable  form).   This  involves: 

a)  the  execution  of  the  four  programs  of  the  syntax  preprocessor; 

b)  the  execution  of  the  ISL  translator  which  is  the  only  program  of 
the  semantics  preprocessor; 

c)  'kountlng"  the  ALGOL  source  for  the  compiler  by  putting  together 
several  pieces  of  ALGOL  code;   some  pieces  are  generated  as  the 
end  result  of  the  syntax  preprocessor,  others  are  generated  by  the 
ISL  translator,  and  some  are  taken  from  the  TWS  Symbolic  Library; 

d)  e.xecuting  the  ALGOL  compiler  on  the  ALGOL  source  program  obtained 
in  (c)  in  order  to  get  the  compiler  for  L  into  machine  code. 

The  TWS  Symbolic  Library  contains,  in  ALGOL  fonn,  all  the  pieces  of 
the  system  which  are  not  language -dependent.   They  are  basically  the  GLOBAL 
package,  the  SCANNER  package  and  the  IL  RECOGNIZER  package.   The  Library  is  kept 
on  B-5500  disk  and  its  routines  are  available  for  Insertion  in  each  compiler 
generated  by  the  system.   The  block  representation  of  the  compiler  in  Figure  10 
shows  clearly  which  pieces  are  generated  by  the  syntax  preprocessor  and  which 
are  generated  by  the  ISL  translator.   The  remaining  pieces  come  from  the  IWS 
Symbolic  Library.   Each  of  the  five  programs  in  the  system  will  now  be  discussed 
separately. 
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2.3.2  TWINKLE  and  the  Syntax -Semantics  Links 

The  first  program  of  the  syntax  preprocessor  and  initial  program  of 
the  whole  system  is  the  TWINKLE  translator.   Its  main  task  is  to  translate  the 
syntactic  description  from  its  original  TWINKLE  form  into  BM   in  tabular  form. 
TWINKLE,  the  syntactic  metalanguage  used  by  the  system,  is  fully  described  by 
Mercer  [3].   Besides  accepting  the  classical  BKF  productions,  TWINKLE  allows  a 
number  of  other  constructs  such  as  the  "Kleene  star"  and  English-like  produc- 
tions that  make  the  syntactic  description  very  clear  and  self -documenting. 
Appendices  B  and  C  present  TWINKLE  descriptions  of  a  small  subset  of  ALGOL 
written  in  two  different  ways.   In  Appendix  B,  only  BNF  productions  were  used 
while  in  Appendix  C  full  advantage  was  taken  of  the  English -like  constructs. 
This  language,  called  DEMALGOL  I,  is  used  in  Chapter  6  to  provide  an  example  of 
a  semantics  description  using  ISL.  I 

The  output  of  TWINKLE  is  a  file  called  TABLESF  which  contains  a  number 
of  tables.   This  file  is  left  on  the  B-5500  disk  and  is  a  common  pool  of  informa- 
tion for  all  the  programs  of  the  system,  i.e.,  the  subsequent  programs  use  the 
information  in  TABLESF  as  input  and/or  add  some  more  tables  to  it.   A  full  dis- 
cussion of  each  table  in  TABLESF  is  beyond  the  scope  of  this  paper  but  a  list 
of  these  tables  with  a  siimmary  description  of  what  they  contain  is  presented  in  < 
Table  k.      The  TWINKLE  translator  produces  another  output  file  besides  TABLESF; 
it  is  called  ACTIONS  and  contains  information  about  the  semantic  action  calls 
that  appeared  in  the  syntactic  description.   This  information  is  then  used  by 
the  ISL  translator  to  match  the  semantic  actions  (or  routines)  definitions  in 
the  semantic  description  with  their  calls  in  the  syntax.   Finally,  it  should  be 
noted  that  in  Figure  10  the  semantic  description  appears  as  input,  with  dashed 
lines,  to  two  different  programs:  the  TWINKLE  translator  and  the  ISL  translator. 
This  indicates  that  the  semantic  description  may  be  input  to  either  of  these 
programs.   The  regular  way  is  to  input  it  directly  to  the  ISL  translator.   How- 
ever, if  desired,  the  semantic  description  may  be  appended  to  the  syntactic 
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TABLE  h 
THE  TABLES  IN  TABLESF 


TABLE  NAME 

* 
1 

* 

H 

n 
o 

* 

to 

DESCRIPTION 

TINDEX 

0 

2,3,C 

Terminal  Indexes:   Contains,  for  each  terminal, 
the  address  of  the  entry  of  the  terminal  in 
SPSTAB. 

NTINDEX 

0 

2,3,C 

Nonterminal  indexes:   Contains,  for  each  non- 
terminal, the  address  of  the  entry  of  the  non- 
terminal in  NONTAB. 

OPRINDEX 

0 

2,3,C 

Operator  indexes:   Contains,  for  each  semantic 
action  name,  the  address  of  the  entry  of  the 
semantic  action  name  in  OPRTAB. 

SPSTAB 

0 

2,3,C 

Special  Symbol  Table:   Contains,  in  a  binary 
tree  structure,  all  the  terminals  of  the  lan- 
guage.  Used  to  initialize  BIGTAB. 

NONTAB 

0 

2,3,C 

Nonterminals  Table:   Contains,  in  a  binary  tree 
structure,  eill  the  nonterminals  of  the  language. 

OPRTAB 

0 

2,3.C 

Operator  Table:   Contains,  in  a  binary  tree 
structure,  all  the  semantic  action  names  used 
in  the  language. 

PRO TAB 

0 

1 

Production  Table:   Contains,  in  a  coded  form, 
the  BNF  productions  that  describe  the  syntax. 

PATTERN 

0 

1,2 

all 

Patterns  Table:  Contains  strings  of  bits  that 
allow  efficient  implementation  of  multiple 
lookaheads,  stack  tests  and  the  implementation 
of  the  "any  symbol"  feature. 

ITODO 

1 

2 

Need  to  do  Table:   Contains  flags  indicating 
which  of  the  Floyd  Productions  are  actually 
needed  for  parsing. 

COMGPS 

1 

2 

2,3,C 

Combined  groups  Table:   Contains  the  combined 
groups  of  Floyd  Productions.   See  [2]  for  an 
explanation. 

ERR  TAB 

1 

1 

3,  C 

Error  Table:   Contains,  for  each  nonterminal, 
a  list  of  all  the  terminals  that  can  follow  it. 
It  is  used  to  recover  from  errors. 
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TABLE  k 
(CONTimjED) 


TABLE  NAME 


o 


m 


M 
Q 

o 


!» 

m 


13 


DESCRIPTION 


GROUPTYPE 


FPTAB 


STKTAB 


LKTAB 


SEMTAB 


XBTAB 


GROUPNAME 


GROUPPTR 


EXCOMGPS 


3.C 


3,C 
3,C 
3,C 

3 
3 


Grouptype  Name  Table:   Contains,  for  each  group 
type,  its  BCD  mnemonic.   (Not  used  at  present. 
Needed  for  future  additions  to  the  system. ) 

Floyd  Productions  Table:   Contains  sets  of  triples 
which  include  all  the  information  needed  for  the 
implementation  of  a  Floyd  Production. 

Stack  Test  Table:   Contains  strings  of  symbols 
for  performing  stack  tests  for  more  than  one 
symbol.   (Not  used  at  present.   Needed  for       i 
future  additions  to  the  system. )  j 

Lookahead  Table:  Contains  strings  of  micro- 
instructions for  implementing  multi-symbol  look- 
ahead  tests. 

Sequential  Semantic  Calls  Table:   Contains  infor- 
mation needed  to  perform  two  or  more  semantic 
action  calls  in  a  row  in  a  single  FP.  i 

Dynamic  Transfers  Table :  Contains  information 
needed  to  perform  a  dynamic  transfer  by  the 
parser. 

Group  Name  Table :  Contains  information  regard- 
ing the  mnemonic  name  associated  with  each  group. 

Group  Pointer  Table:  Contains,  for  each  group,  a 
pointer  to  its  starting  location  in  FPTAB. 

Executable  FP's  Combined  Groups  Table:   Same  as 
COMGPS  for  use  with  executable  FP's. 


The  program  numbers  mean:  0  -  IWINKLE  Translator,  1  -  Floyd  Produc- 
tion Generator,  2  -  Parser  Tables  Generator,  3  -  ALGOL  Code  Generator,  C  -  the' 
resulting  COMPILER,  all  -  all  five  above. 
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description  and  be  input  to  the  TW  NKLE  translator.   This  program  will  separate 
the  two  descriptions  and  insert  the  semantics  in  the  file  ACTIONS,  along  with 
the  information  that  is  normally  there.   The  TWINKLE  compiler  will  then  initiate 
the  execution  of  both  the  FP  generator  and  the  ISL  translator.  At  the  end  of 
the  process,  the  ISL  translator  or  the  ALGOL  code  generator  (whichever  ends  last) 
assembles  all  the  pieces  of  the  compiler  and  Initiates  the  execution  of  the  ALGOL 
compiler  to  compile  the  required  compiler.   Thus  it  is  possible  to  obtain  the 
final  compiler  simply  by  executing  the  1WINKLE  compiler  (with  the  proper  options 
set)  and  presenting  to  it  both  the  syntactic  and  semantic  descriptions.   The 
different  types  of  syntax- semantics  links  present  in  the  system  will  now  be  dis- 
cussed. 

2.3.2.1  Semantic  Action  Calls 

The  main  syntax -semantic  link  in  the  system  is  the  semantic  action 
call.   It  has  already  been  established  that  the  syntactic  description  contains 
BRF  productions  (or  generalized  forms  of  BNT  productions)  and  the  semantic  des- 
cription contains  semantic  routines  (the  term  "semantic  action"  is  used  inter- 
changeably with  "semantic  routine").   The  link  between  these  two  is  provided  by 
semantic  action  calls  of  the  type:  @S  <identifier>  placed  anywhere  (except  at 
the  beginning)  in  a  BW   production,  meaning  that  when  the  parser  reaches  pre- 
cisely that  point  in  a  production  control  must  be  given  to  the  semantic  action 
labelled  by  the  <identifier>  .   After  the  execution  of  the  semantic  routine,  the 
parser  resiomes  operation.   Thus,  the  following  are  examples  of  semantic  action 
calls: 

<HEAD>  :  :=  #BEGIN  @S  3  <DECLARATION  PARI>  #;  @S  ENLECPART 
<TyPE  LISI>  :  :=  <TrFE  LIST>  #,  <*I>  @S  7  |  <*I>  @S  7 

The  constructs  above  are  all  valid  in  TWINKLE.   The  symbol  #  precedes  every 
terminal  and  the  construct  <*I>  is  the  meta-terminal  <identifier>.   Similarly 
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<*1C>  is  any  number  and  <*S>  is  any  st-'ing.   Note  also  that,  in  the  definition  of 
semantic  action  calls,  <identifier>  is  taken  in  a  more  general  sense  to  include 
a  beginning  digit.   Thus  numbers  are  also  legal  names  for  semantic  actions. 
Only  BKF-like  TWINKLE  constructs  are  used  for  exemplifying  the  syntax- semantics 
links.  The   addition  of  semantic  calls  to  the  other  TWINKLE  constructs  is  similar 
and  is  discussed  in  Chapter  6.   For  a  complete  description  of  the  syntax  of  the 
semantic  action  calls,  see  Mercer  [3]. 

The  first  example  above  means  that,  when  recognizing  a  <HEAD>,  immedi- 
ately after  placing  #BEGIN  in  MSTACK,  the  semantic  action  named  "3"  must  be  exe- 
cuted.  Then,  after  the  recognition  of  a  <DECLARATION  PART>  and  a  ' ';"  the  semantic 
action  named  "ENDECPART"  should  be  executed.   Note  that  when  an  action  call  is  at 
the  end  of  a  production,  it  is  executed  immediately  before  the  reduction  takes 
place.   In  the  second  example,  a  <TYPE  LIST^  is  recursively  defined  as  identi- 
fiers separated  by  ",  ".  After  each  identifier  is  placed  in  MSTACK,  the  semantic 
action  named  'V"  is  to  be  executed. 

It  should  be  recalled  that  both  BIGTAB  and  MSTACK  are  in  the  scope  of 
the  semantic  routines  and  have  fields  labelled  SEM  which  are  reserved  for  seman-  ' 
tic  information.   Thus  one  of  the  things  often  performed  by  a  semantic  action  is  , 
to  insert  semantic  information  in  a  MSTACK  or  BIGTAB  SEM  field  thus  associating  : 
"semantics"  with  the  syntax  that  was  placed  there  by  the  parser.  All  the  fields 
of  MSTACK  or  BIGTAB  can  also  be  interrogated  by  a  semantic  action  to  retrieve 
information  left  there  by  previous  executions  of  semantic  actions  or  by  the 
parser.   Semantic  routines  are  also  used  for  many  other  things  such  as  building 
identifier  tables  and  generating  object  or  intermediate  language  code. 

It  is  vital  that  the  user  know  what  the  situation  of  MSTACK  will  be 
when  a  semantic  action  is  called.   In  the  first  example,  for  instance,  when  the 
routine  ENDECPART  is  called,  it  is  known  that  the  positions  TOP,  TOP-1  and 
TOP-2  of  MSTACK  must  contain,  respectively,  the  terminal  ";"^the  terminal  or  meta 
terminal  that  began  the  declaration  part,  and  the  tenninal  #BEGIN.  Note  also,  thf, 
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upon  restarting  of  the  parse,  a  ■ eduction  will  occur  thus  destroying  TOP  and 
TOP-1  and  leaving  the  previous  TOP-2  as  the  new  top  of  MSTACK.   Therefore  any 
useful  semantic  information  that  might  be  stored  in  the  SEM  field  of  TOP  or 
TOP-1  must  be  saved  somewhere  else  by  EEDECPMT  or  it  will  be  lost. 

2.3-2.2  Semantic  Tests 

Consider  the  two  following  BKF  productions  that  are  present  in  the 
syntactic  description  of  DEMALGOL  I: 

<ARITHMETIC  PRIMimY>  :  :-  <*I>  @S  17 
<BOOLEM  PRBIARY>  :  :  =  <*!>  @S  I9 

The  language  thus  defined  is  obviously  ambiguous  if  one  considers  that 
an  arithmetic  assignment  statement  and  a  boolean  assignment  statement  may  both 
be  of  the  form  <*!>  f-  <*!>  .   Thus  context  cannot  resolve  the  conflict  and  there 
is  ambiguity,  i.e.,  the  parser  cannot  know,  at  that  point,  whether  to  call  action 
"17"  and  make  a  reduction  to  an  <ARITHMETIC  PRIMARY>  or  to  call  "l9  "  and  make  a 
reduction  to  a  <BOOLEAN'  PRIMARY>  .   There  is,  howevei?  one  way  to  solve  the  prob- 
lem: if  the  identifier  has  been  declared  of  type  INTEGER  then  the  first  produc- 
tion must  apply;  else,  if  it  has  been  declared  of  type  BOOLEAN  the  second 
production  is  to  be  chosen.   This  is,  in  essence,  syntactic  information  since  it 
would  be  possible  to  write  a  syntactic  description  of  DEIVLALGOL  I  that  would 
"remember"  what  an  identifier  had  been  declared.   Such  a  description,  however, 
would  have  to  use  Context  Sensitive  productions.   Therefore,  the  difficulty 
arises  from  the  fact  that  BKF  is  not  powerful  enough  to  describe  all  of 
DEMALGOL  I  (or  all  of  any  other  nontrivial  ALGOL-like  language).   The  solution 
is  to  describe  whatever  subset  of  the  syntax  BNF  is  capable  of  and  leave 
the  rest  to  the  semantics.   Thus,  semantic  routines  must  keep  tables  of  what 
type  each  identifier   has  been  declared  and  they  should  be  able  to  transmit 
this  information  to  the  parser  at  the  appropriate  time.   This  is  done  by 


means  of  a  special  type  of  semantic  action  call  called  semantic  test  which  is 
placed  immediately  following  the  symbol  (terminal,  meta-terminal  or  non- 
terminal) that  would  have  caused  the  ambiguity.   Syntactically,  a  semantic - 
test  is  similar  to  a  semantic  call  except  that  @T  is  used  instead  of  @S. 
A  semantic  test  routine  may  do  anything  that  a  regular  semantic  routine  may 
do.   It  must,  however,  also  set  a  fixed  global  boolean  variable,  called 
SEMANTIC lEST,  either  true  or  false  recording  as  the  symbol  in  the  stack  is 
semantically  matched  or  not,  respectively.   A  semantic  test  could  be  described 
technically  as  a  method  for  the  parser  to  retrieve^  from  the  semantics,  in- 
formation which  is  actually  syntactic  but  which  was  left  to  the  semantics 
due  to  the  impossibility  of  describing  context  sensitive  languages  with  BKF 
productions. 

Thus,  in  the  example  given  at  the  beginning  of  this  section,  one 
shoiild  add  a  semantic  test  to  either  one  of  the  two  productions.  For  example, 
the  first  production  co\ild  be  made. 

<ARITHMETIC  PRB1ARY>  :  :  =  <-^I>  @T  10  @S  Y[ 

Semantic  routine  *'10"  must  perform  as  one  of  its  acts  the  following:   check 
the  table  of  declarations  (that  must  have  been  previously  built  by  other 
semantic  actions)  and  set  SEMANTIC  TEST  to  true  if  the  identifier  which  is 
on  top  of  MSTACK  has  been  declared  of  type  INTEGER,  set  it  to  false  in  case 
of  a  type  BOOLEAN  (DEMALGOL  I  has  no  REAL  type).   Note  that  a  semantic  test 
must  immediately  follow  the  term  it  modifies.   Therefore,  no  semantic  test 
may  be  preceded  by  a  semantic  action  call.   The  use  of  semantic  tests 
presents  some  difficulties  which  are  described  by  Beals  [2] ,  page  33* 

2.3.2.3  Other  Links 

It  has  been  shown  that  the  main  system  of  syntax -semantics  links 
In  the  system  is  provided  by: 


a)  Siemantic  action  call3 

b)  aemantic  tests 

c)  the  global  boolean  variable  SEMANTIC TEST 

d)  presence,  in  MS TACK  and  BIGTAB,  of  both  syntactic  and  semantic 
fields  allowing  association  of  semantics  to  syntactic  elements. 

However,  recalling  the  fact  that  all  the  scanner  and  parser  procedures 
and  variables  are  global  to  the  semantic  routines  and  thus  are  in  their  scope 
(see  Figure  h),  all  these  elements  could  be  considered  secondary  syntcLX- 
semantics  links  since  they  can  be  checked  and/or  modified  by  a  semantic 
routine.   Three  of  these  secondary  links  are  used  very  often.   Firstly,  the 
line  printer  file,  in  which  the  parser  messages  are  written,  may  also  be  used 
by  a  semantic  routine  to  write  some  information  (probably  debugging  aids). 
Thus  syntactic  and  semantic  messages  will  appear  printed  together,  in  the 
correct  sequence.   Secondly,  the  integer  variable  NUMERRS  which  the  parser 
increments  each  time  it  finds  an  error,  may  also  be  incremented  by  semantic 
routines  each  time  a  semantic  error  is  detected  (for  example,  an  identifier 
used  in  an  expression  has  never  been  declared).   Thus,  MIMERRS  =  0  at  the 
end  of  a  compilation  will  mean  completely  successful  compilation  rather  than 
simply  no  syntactic  errors.   Thirdly,  the  scanner  control  variables  (see 
Table  3)  may  be  modified  by  a  semantic  routine  thus  providing  the  ability  to 
change  the  scanner  behavior  when  recognizing  particular  types  of  constructs 
(for  example,  when  parsing  a  FORMAT  declaration  15  should  be  recognized 
character  by  character  instead  of  as  an  identifier) . 

It  should  be  noted  that  all  the  discussion  of  syntax-semantics 
links  was  for  pass  1  only.   For  pass  i  (i>l),  the  same  principles  apply 
except  that  (obviously),  semantic  tests,  BIGTAB  and  scanner  control  variables 
do  not  exist  any  more. 


2.3.3  The  Floyd  Productions  Generator 

The  main  task  of  the  FP  Generator  is  to  transform  the  BNF  tabular 
description  of  the  syntax  (received  from  the  TWINKLE  translator  in  PROTAB  of 
TABLESF)  to  a  set  of  Floyd  Productions  (FP's)  which  are  the  basis  of  a 
deterministic  parsing  algorithm.   This  program  and  the  transformation  algorithm 
BNF  ->  FPL  have  been  described  by  Beals  [2].   TABLESF  is  also  used  as  output 
by  the  FP  Generator^  however  its  main  output,  i.e.  the  set  of  FP's,  is  written 
on  B-5500  disk  as  a  separate  file  called  FLOYDP.   The  reason  for  this  is  that 
the  file  is  large  and  it  is  needed  only  between  the  FP  Generator  and  the  PT 
Generator.   Therefore  it  would  be  a  waste  of  space  to  keep  it  in  TABLESF  at 
all  times  as  is  done  with  most  of  the  other  tables. 

2. 3-^  The  Parser  Tables  Generator 

The  main  task  of  the  PT  Generator  is  to  transfonn  the  FP's  received 
from  the  FP  Generator  in  the  file  FLOYDP  into  a  very  compact  set  of  'parser 
instructions"  and  other  tables  that  can  actually  be  used  by  the  parser. 
TABLESF  is  also  used  as  both  input  and  output.   The  table  of  "parser  instruc- 
tions" is  FPTAB  of  TABLESF  and  it  contains  triples  of  words.   Each  triple 
contains  all  the  information  needed  for  implementing  a  Floyd  Production  such 
as:   stack  tests  to  be  performed,  semantic  tests  to  be  performed,  lookahead 
symbols  to  check,  which  semantic  routine(s)  to  call  if  the  tests  succeed,  stack 
reductions  to  be  made,  and  which  FP  to  apply  next. 

2.3.5  Interpretive  and  Executable  Parts  -  The  ALGOL  Code  Generator. 

In  order  to  explain  the  function  of  the  ALGOL  Code  Generators,  the 
concept  of  interpretive  code  must  be  established  and  compared  with  the  concept 
of   non-interpretive  (or  executable)  code.   Non- interpretive  or  executable 
code  is  taken  here  in  its  usual  meaning:   a  piece  of  code  that  can  be  directly 
executed  by  a  machine,  i.e.,  machine  code.   Interpretive  code  is  understood 
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as  a  piece  of  code  to  be  "execut  d"  by  an  interpreter,  i.e.,  a  program  that 
reads  the  interpretive  code  and  "obeys"  it.   Thus  the  interpreter  has  actually 
the  role  of  a  simulator  that  simulates  in  the  real  machine  an  imaginary  machine 
that  accepts  the  interpretive  code.   Interpretive  systems  are  frequently  called 
" table -driven" .   Their  advantage  is  the  use  of  a  more  compact  program;  the 
interpreter,  usually  small,  is  the  only  program  always  in  core  and  the  instruc- 
tions for  the  interpreter  are  read  from  the  tables  as  needed.   On  the  other 
hand,  an  executable  system  allows  faster  execution  (since  the  simulation  is 
avoided)  usually  at  the  expenses  of  a  larger  program  since  the  previous  table 
has  been  transformed  into  a  program.   Thus  this  seems  to  be  another  application 
of  the  classical  speed-space  trade-off,  except  that  in  the  B-5500  system  this 
trade-off  ultimately  leads  to  a  choice  of  slow  execution  and  little  overlay 
versus  fast  execution  and  much  overlay.   Therefore,  in  the  B-5500,  an 
executable  system  may  end  up  to  be  slower  (in  total  time)  than  an  inteipretive 
system  since,  for  very  large  tables,  the  resulting  executable  program  is  very 
large  and  the  shorter  execution  time  is  more  than  compensated  by  the  larger 
overlay  time. 

At  the  end  of  the  syntactic  preprocessor,  one  must  choose  between  an 
interpretive  system  and  an  executable  system.   Three  different  pieces  of  the 
final  compiler  may  be  either  interpretive  or  executable:   the  FP  package,  the 
LK  procedure  and  the  FILLTAB  procedure  (those  pieces  are  marked  by  a  dotted 
underline  in  Figure  k) .     Any  combination  of  interpretive  and  executable  for 
these  three  pieces  is  allowed  and  can  be  requested  by  using  TWIMLE  control 
options.   If  one  of  the  pieces  is  interpretive,  then  an  interpreter  for  it  is 
taken  out  of  the  TWS  Symbolic  Library  and  inserted  in  its  place  in  the 
compiler.  At  compile  time,  this  interpreter  will  use  TABLESF  as  its  source 
of  code.   This  was  indicated  in  Figure  10  by  dotted  lines.   If  a  piece  is 
executable,  then  the  Uth  program  of  the  syntactic  preprocessor  must  be  run. 
This  program,  the  ALGOL  Code  Generator,  takes  the  code  for  the  piece  out  of 


TABLESF  and  translates  it  into  ALGOL  Code  which  is  then  inserted  in  the  proper 
position  in  the  compiler.   That  part  then  does  not  need  TABLESF  at  compile 
time.   This  possibility  was  indicated  in  Figure  10  with  dashed  lines.   The  two 
extreme  cases  are : 

a)  All  3  pieces  interpretive.   In  this  case,  the  ALGOL  Code  Generator 
does  not  have  to  be  run..   The  final  compiler  is  language -dependent 
only  due  to  the  semantic  routines.  The  syntactic  analyser  is 
general  purpose  and  will  receive  at  run  time  (and  for  each  run) 
the  information  about  the  syntax  of  L  from  TABLESF.   This 
compiler  is  faster  to  generate  (since  one  of  the  programs  is  not 
used)  and  is  probably  the  best  to  use  for  the  debugging  stage  of 
implementation  of  a  new  language  with  the  system. 

b)  All  3  pieces  executable.   In  this  case  the  final  compiler  contain; 
in  itself  all  the  information  about  the  language  (i.e.,  both 
syntax  and  semantics)  and  TABLESF  is  not  needed  at  compile  time. 
For  small  languages,  this  will  probably  be  the  choice  for  the 
final  compiler  since  it  is  likely  to  be  the  fastest.   For  large 
languages  only  timing  tests  can  indicate  the  best  combination  of 
executable  and  interpretive  pieces. 

2.3.6  The  ISL  Translator 

The  inputs  for  the  ISL  translator  are  the  semantic  description  of 
the  language  in  ISL  (either  input  directly  or  given  to  the  TWINKLE  translator 
and  passed  to  the  ISL  translator  as  part  of  the  file  ACTIONS)  and  the  file 
ACTIONS  providing  information  about  the  code  number  TWINKLE  associated  with 
each  semantic  action  name  foimd  in  the  syntax.   The  ISL  translator  must  then 
associate  the  same  code  number  to  the  definitions  of  those  actions  in  order 
to  match  a  semantic  action  definition  with  its  call.   The  main  task  of  the 
ISL  translator  is  to  translate  each  piece  of  the  semantic  description 
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(one  for  each  pass  and,  if  the  number  of  passes  is  not  1,  also  one  for  HEAD) 
into  ALGOL  and  insert  it  into  the  appropriate  position  in  the  compiler.   Since 
ISL  is  basically  an  extension  of  ALGOL,  the  ISL  translator  must  detect  the 
additional  (i-e.,  non-ALGOL)  constructs  and  translate  them  into  ALGOL 
preserving,  unmodified,  what  was  already  in  ALGOL.   It  must  also  build  the 
procedure  EXEC(n)  described  in  Section  2.2.1-3  which  must  be  available  for 
the  parser  to  call  when  it  has  to  obey  a  semantic  action  call. 

This  completes  the  general  description  of  the  complete  TWS  System. 
The  rest  of  this  paper  will  be  devoted  to  a  detailed  discussion  of  ISL. 


he 


3-   DESIGN  Mm   IMPLEMEMIATION 

This  chapter  contains  a  discussion  of  the  design  of  ISL  and  the 
approaches  adopted  in  its  implementation. 

3-1  Design  Considerations 

3.1.1  Critique  of  FSL 

The  Formal  Semantic  Language  (FSL)  introduced  by  Feldman  [lO]  and 
discussed  by  Northcote  [ll]  was  a  major  advance  in  the  art  of  implementing 
TWS's.   Its  main  advantage  is  the  facilities  provided  for  declaring  and  manip- 
ulating tables,  stacks  and  other  data  structures  not  usually  available  in 
general  purpose  programming  languages.   This  simplified  the  writing  of  a  brute- 
force  semantic  description  of  a  language  and  the  res\ilting  program  is,  to  a 
certain  extent,  clear  and  self -documenting.  However,  if  one  considers  the 
goals  and  characteristics  of  the  ILLIAC  IV  TWS,  the  inclusion  of  FSL  in  this 
system  would  present  problems  in  the  following  four  different  areas. 

1)  Although  FSL  embodies  several  ALGOL  features,  its  notation  is,  in  ; 
several  cases,  considerably  different  than  the  ALGOL  one.   In  fact,  certain 
representations  are  downright  cumbersome.   In  a  table  operand,  for  example,  the 
user  must  submit  a  string  of  commas  with  a  "$"  in  the  proper  place  to  indicate 
which  column  of  the  table  is  to  be  referenced.  This  makes  human  adaptation  from 
ALGOL  to  FSL  a  non-trivial  effort. 

2)  It  seems  that  FSL,  probably  unintentionally,  embodies  some  particu- 
larizations  that  make  it  specially  powerful  only  for  implementing  one-pass  com- 
pilers for  ALGOL-like  languages  to  be  run  in  a  conventional  (sequential)  computer.! 
Despite  the  fact  that  a  certain  amoiint  of  part ic\ilarizat ion  is  probably  unavoid- 
able (and  may  be  even  desirable)  in  order  to  generate  good  code,  the  restrictions 
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above  co\ild  not  be  tolerated  in  a  system  whose  basic  feature  is  the  production 
of  n-pass  compilers  and  the  main  application  of  which  has  been  to  Implement 
languages  for  a  highly  parallel  machine. 

3)  With  regard  to  (2)  above^,  the  run-time  features  (RTABLE,  RSTACK, 
etc. )  and  the  use  of  the  CODE  brackets  to  manipulate  them  seem  to  be  a  particu- 
larly weak  area.   Besides  being  complicated  to  use,  the  implementation  of  these 
facilities  is  extremely  machine -dependent.  Machine  independence  was  to  be  ob- 
tained by  having  "the  machine  dependent  aspects  of  primitives  embedded  in  the 
compiler  kernels".   This  would  not,  however,  fit  in  the  ILLIAC  IV  IMS   approach 
of  leaving  machine  dependence  to  be  dealt  with,  at  pass  2,  by  user  implemented 
IL  operators. 

h)     Being  a  compiler  language,  FSL  needs  a  complicated  translator. 
This  either  limits  the  use  of  FSL  to  the  few  machines  for  which  such  a  translator 
is  available  or  obliges  the  user  to  undertake  the  major  project  of  writing  one 
himself. 

3.1.2   The  ISL  Approach 

Since  the  facilities  for  declaring  and  manipulating  tables,  stacks, 
etc.  were  considered  to  be  one  of  the  main  advantages  of  FSL,  they  were  retained 
in  ISL.   The  problems  identified  in  FSL  were  dealt  with  in  ISL  using  the  follow- 
ing approaches: 

1)  ISL  notation  was  made  as  ALGOL-like  as  possible.   In  fact,  most 
ISL  constructs  very  closely  resemble  ALGOL  procedure  calls.   Besides,  the  simple 
fact  that  ISL  is  an  extension  of  ALGOL  makes  ALGOL  available  as  part  of  ISL  thus 
making  the  implementation  of  anything  already  present  in  ALGOL  unnecessary. 
Therefore  ALGOL  prograinmers  (and,  in  particular,  BeA  programmers)  find  ISL  a 
very  "natural"  extension  of  ALGOL,  easy  to  learn  and  use. 

2)  Several  FSL  features  which  were  deemed  to  be  too  directly  concerned 
with  the  implementation  of  one-pass  compilers  were  not  defined  in  ISL  since  they 
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are  troublesome  to  implement  and  probably  would  not  be  very  useful  in  the 
system.   This  includes  FSL's  FLAD,  CHAIN  and  ASSIGN  statements.   When  needed, 
the  equivalent  of  these  constructs  can  be  easily  simulated  using  regular  ISL 
or  BeA  features. 

3)  No  facilities  are  provided  in  ISL  to  generate  machine  code  or  to 
decl3.re  and  manipulate  run -time  stacks  and  tables.   It  was  felt  that  the  imple- 
mentation of  these  features  is  too  machine  dependent  and,  according  to  the 
generalized  IL  philosophy,  should  be  left  to  user  defined  IL  operators.   Nor- 
mally machine  code,  for  example,  is  generated  with  BeA  WRITE  statements  in  the 
semantic  routines  of  the  last  pass.   This  also  allows  great  freedom  in  the 
FORMAT  of  the  output  so  that  when  assembly  language  is  to  be  the  final  resiilt, 
it  can  be  written  in  the  format  expected  by  a  particular  assembler.  While  the 
machine  language  output  is  provided  by  the  user,  intermediate  language  output 
and  input  statements  are  available  in  ISL.   This  is  made  possible  by  the  fixed, 
simple  syntax  of  the  IL.   Intermediate  language  operators  and  operands  can  be 
emitted  using  the  ISL  CODE  statement.   IL  input  is  automatically  provided  by  the ; 
IL  Recognizer.   However,  the  user  can  also  cause  the  IL  string  to  be  read  by 
using  the  procedures  described  in  section  2.2.2. 

k)      The  approach  of  defining  ISL  as  an  extension  to  ALGOL  leads  to 
two  great  advantages.   Firstly,  all  the  power  of  BeA  is  given  to  the  ISL  user 
including  such  valuable  features  as  mult i -dimensional  arrays  and  recursive  pro- 
cedures.  The  power  of  these  constructs  guarantees  that  the  most  tricky  semantic 
actions  may  be  described  in  ISL.   Secondly,  ISL  can  be  easily  implemented  with  a 
two-pass  compiler  in  which  the  first  pass  detects  the  ISL  (i.e.,  non-ALGOL)  con- 
structs and  translates  them  into  ALGOL  preserving,  unmodified,  the  ALGOL  con- 
structs.  A  pure  BeA  program  is  then  obtained  which  is  translated,  in  the  second 
pass,  to  machine  code  by  the  BeA  compiler.   Thus  the  implementation  of  ISL  in  a 
new  machine  involves  only  the  relatively  simple  conversion  of  the  first  pass 
(henceforth  called  the  ISL  translator)  from  BeA  to  the  local  version  of  ALGOL 
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since  an  ALGOL  compiler  is  usual].y  available.   Obviously  this  approach  will 
yield  good  code  only  as  far  as  the  ISL  constructs  can  be  efficiently  defined  in 
terms  of  ALGOL.   This  was  possible  in  the  system's  ISL  translator  due  to  the 
availability,  in  BeA,  of  bit  manipulation  facilities.   Since  these  facilities 
are  not  likely  to  be  encountered  in  other  ALGOL  versions,  the  implementation  of 
ISL  for  a  non-Burroughs  machine  may  not  be  as  simple  as  outlined  above. 

3.2  Implementation 

Two  different  ISL  translators  were  written  for  the  system:   a  brute - 
force  ISL  translator  and  a  IWS  ISL  translator.   Only  the  brute-force  translator 
will  be  described  in  some  detail,  but  speed  comparisons  will  be  given  for  the 
two  versions. 

3.2.1  The  Brute -Force  ISL  Translator 

The  brute-force  ISL  translator  was  manually  written  in  BeA.   It  is  a 
program  consisting  of  approximately  3000  source  cards  and  translates  a  "typical" 
ISL  program  into  BeA  at  a  rate  of  about  2000  cards  per  minute.   The  test  program 
used  was  an  actual  2000  card  long  semantic  description  of  a  language  and  the 
typical  density  of  ISL  constructs  is  of  the  order  of  one  construct  per  two  cards. 

Since  brute-force  semantic  descriptions  of  complex  programming  lan- 
guages can  be  extremely  large,  it  was  vital  that  the  ISL  translator  have  a  good 
speed.   In  order  to  attain  this  goal,  the  syntax  of  ISL  was  carefully  formiLLated 
to  allow  efficient  parsing  by  the  ISL  translator,  i.e.,  ISL  constructs  must  be 
quickly  recognized  and  isolated  with  a  minimum  parsing  of  the  ALGOL  constructs 
interspersed  among  them.   This  was  done  by  defining  that  all  ISL  constructs  be 
characterized  by  an  identifier  immediately  preceded  by  the  character  "$"  (dollar 
sign).  Moreover,  the  appearance  of  the  "$"  in  column  one  of  a  card  was  forbid- 
den.  A  free  "$"  (i.e.,  not  embedded  in  a  string)  cannot  occur  in  BeA  except  in 
column  1  (and  then  it  indicates  a  BeA  control  card).  When  an  ISL  construct  has 
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parameters  they  must  appear^  enclosed  in  parentheses,  after  the  $  <ISL  construct 
identifier>  that  mark  it. 

Figure  11  presents  the  basic  "block  structure  of  the  brute -force  ISL 
translator.   The  main  part  is  the  "basic  parsing  algorithm"  which  is  treated  in 
the  next  section.   Then  there  is  one  block  of  code  for  each  ISL  construct.   The 
basic  parsing  algorithm  gives  control  to  the  block  of  code  that  handles  a  spe- 
cific ISL  construct  when  it  has  found  that  construct.  Moreover,  the  string  of 
arguments  (if  any)  for  the  construct  is  known  to  be  ISL-free  (i.e.,  nesting  has 
been  taken  care  of)  and  is  placed  in  an  array  called  ARGUMENT.   The  locations 
STARTPAR  and  EKDPAR  are  also  set  by  the  parsing  algorithm  to  contain  the  loca- 
tions in  ARGUMENT  at  which  the  string  of  parameters  start  and  end.  With  this 
information,  the  block  of  code  that  handles  the  constinict  can  translate  it,  put 
the  resulting  BeA  code  in  the  array  RESULT  and  call  a  procedure  named  RETURN  that 
picks  the  result  and  gives  control  back  to  the  parsing  algorithm.   These  blocks 
of  code  are  referred  to  as  HVIPLXXK  where  XXX  stands  for  the  name  of  the  ISL  con- 
struct the  block  handles.   The  IMPLXXX  blocks  are  relatively  straightforward  and 
their  implementation  will  not  be  described  except  for  some  comments, in  Chapter  k, 
about  the  type  of  BeA  code  generated  by  the  different  ISL  constructs.   The  basic 
parsing  algorithm,  however,  deserves  further  discussion. 

3-2.1.1  The  Basic  Parsing  Algorithm 

The  effect  of  the  parsing  algorithm  was  described  in  the  preceding 
section.   Its  main  task  is  to  take  care  of  nesting  of  ISL  constructs  so  that 
when  several  ISL  constructs  appear  nested  the  parsing  algorithm  first  calls 
IMPLXXX  for  the  innermost  construct.   The  result  of  this  constiruct  is  then  in- 
serted in  place  and  scanned  for  further  ISL  constructs  (thus  an  ISL  construct 
may  generate  other  ISL  constructs  in  a  local  multi-pass  translation).  When 
there  are  none,  IMPLXXX  is  called  for  the  second  construct  (from  the  inside) 
which  is  now  known  not  to  contain  ISL  in  its  string  of  parameters  and  the 
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utility  PROCEDURES: 


SCATOJER;  READACARD; 


ISL  construct  name  decoder^ 


RETURN;  Bracket  counter,  etc. 


Basic  Parsing  Algorithm 


IMPLTABLE:   (block  of  code  that 
implemf^nts  $  TABLE  declarations) 


IMPLSTACK:   (block  of  code  that 
implements  $STACK  declarations) 


n^PLEMD:   (block  of  code  that 

implements  the  $EKD 

statement ) 


^ 


> 


one  block  of 
code  for  each 
ISL  construct 


Figure  11.   Block  diagram  of  the  brute -force  ISL  translator. 
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procedure  continues  until  the  outermost  construct  is  translated.   The  basic 
element  in  the  analysis  of  nesting  is  a  stack  called  NESTACK.   Its  two  main 
fields  are  CONSTRUCT  which  stores  the  name  of  the  construct  and  STARTPAR  which 
points  to  the  location  in  ARGUMENT  at  which  the  string  of  parameters  for  this 
construct  begins.   The  functioning  of  the  parsing  algorithm  can  best  be  under- 
stood by  studying  Figure  12  which  presents  a  flow  diagram  for  the  brute-force 
ISL  translator  detailing  utilization  of  the  parser.   Note  that  the  scanner  scans 
elements  from  INPUT  which  may  be  either  a  card  image  or  the  array  ARGUMENT.   Note 
also  that  the  top  of  NESTACK  contains  CONSTRUCT  and  STARTPAR  for  the  construct 
presently  being  translated  while  the  positions  further  down  contain  that  informa- 
tion for  successive  outer  levels  of  nesting. 

3.2.1.2   The  Parsing  Algorithm  as  Applied  to  the  Implementation  of  a  Class  of 
ALGOL  Extensions 

In  Figure  11^  one  can  notice  that  the  only  parts  which  depend  on  parti- 
cular ISL  constructs  are  the  IMPLXXX  blocks  and  the  ISL  construct  name  decoder. 
The  other  procedures  and, particularly,  the  basic  parsing  algorithm  could  be  used  ; 
to  recognize  any  extension  of  ALGOL  with  non-ALGOL  constructs  of  the  type: 

$<construct  identifier>  (<string  of  parameters>) 

All  the  user  would  have  to  do  is  to  provide  an  IMPLXXX  block  for  each  construct 
and  to  insert,  in  the  construct  name  decoder,  the  names  (identifiers)  associated 
with  each  construct.   At  first,  it  seems  that  these  extensions  of  ALGOL  might  as 
well  be  implemented  with  a  standard  deck  of  ALGOL  procedures  which  would  be  in- 
serted at  the  beginning  of  each  program,  each  procedure  defining  (or  implement- 
ing) one  construct.   However,  the  extensions  that  can  be  obtained  with  this 
simple  method  are  very  trivial  due  to  the  restrictions  imposed  by  the  ALGOL 
rules  for  use  of  procedures.   Much  more  sophisticated  extensions  can  be  imple- 
mented using  the  kernel  of  the  ISL  translator  as  described  above.   In  fact,  this 
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1     i    i 


Make  INPUT  from  cards; 
Reads  1  source  card 


output  the 
card  as  is 


no. 


I 


Point  the  scanner  to  the  1st 
column  of  the  card 


A 


yes 
-4- 


Figure  12.   Flow  diagram  of  the  brute -force  ISL  translator. 
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Identify  the  ISL  construct;  Push  NESTACK 
with:   in  CONSTRUCT;,  the  name  of  the  con- 
struct and  in  STAETADD  the  location  of  ARGU- 
MENT where  the  string  of  parameters  will  be 
placed 
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no 


Point  the  scanner  to  the  1st  element  of 
the  string  of  parameters 


Copy  the  next  element  from  INPUT  into  ARGUMENT 


yes 

-4- 


nake  INPUT\ 
from  cardo) 
read  next 

source  card 

and  point 
canner  to 
he  1st 

element  in 

the  card 


Execute  block  IMPLXXX  for  the  data  on  top  of  NESTACK; 
this  block  translates  the  ISL  construct  and  places  the 
result  in  RESULT,  the  call  RETURN  which  pops  NESTACK, 
transfers  the  result  to  ARGUMENT  and  points  the  scanner 
to  the  1st  element  of  the  result  in  ARGUMENT 
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Figure  12.   Continued. 
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method  could  be  considered  a  very  primitive  TWS  in  which  the  syntax  is  almost 
I  fixed  and  the  IMPLXXK  blocks  are  the  semantic  routines.  A  number  of  set  decla- 

rations  and  set  manipulation  statements  were  defined  in  a  SET -ALGOL  extension 

to  test  the  application  of  the  kernel  of  the  ISL  translator  in  its  implementa- 
■  tion.   The  method  worked  well  and  SET -ALGOL  was  partially  implemented  using 

such  a  kernel. 

3.2.2  The  TWS -ISL  Translator 

Once  the  brute -force  ISL  translator  was  completed  and  integrated  into 
the  system  the  TWS  itself  could  be  used  to  implement  ISL.  This  was  actually 
done  and  the  resulting  one-pass  translator  has  been  named  the  TWS-ISL  trans- 
lator.  Note  that  for  this  application  the  semantics  of  ISL  were  described  in 
ISL.   The  advantages  of  the  TWS-ISL  translator  over  the  brute-force  one  are 
basically  two.   First,  the  TWS-ISL  translator  is  "easily"  modifiable  by  anyone 
familiar  with  the  TWS  system.   This  is  a  very  important  feature,  as  it  facili- 
tates future  extensions  of  ISL.   Secondly,  TWS-ISL  is  a  more  sophisticated  ver- 
sion of  ISL  than  brute-force-ISL. 

The  main  disadvantage  of  the  TWS-ISL  translator,  when  compared  with 
the  brute-FORCE  one,  is  its  speed:   approximately  5OO  cards  per  minute  against 
2000  for  the  brute -force.   This  is,  in  fact,  a  remarkable  performance  for  the 
TWS-ISL  translator  since  it  does  not  have  the  initial  scanning  to  deal  immedi- 
ately with  non-ISL  cards  which  is  largely  responsible  for  the  speed  of  the  care- 
fully hand  coded  brute-force  translator.   It  is  hoped  that  the  introduction  of 
this  optimization  and  improvements  being  completed  in  several  areas  of  the  system 
will  boost  the  speed  of  the  TWS-ISL  translator  and  make  it  comparable  with  the 
brute-force  one.   This  will  then  be  discarded  and  the  system  will  be  "closed", 
i.e.,  both  the  syntactic  and  semantic  metalanguages  will  use  translators  im- 
plemented with  the  aid  of  the  system  itself. 
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This  chapter  presents  a  description  of  ISL.   Semantics  is  described 
in  English  and  syntax  definitions  are  given  using  BNF  productions  in  an  infor- 
mal way  or  via  English  descriptions.   The  formal  BHF  syntax  for  ISL  is  presented 
in  Appendix  A,  each  production  being  numbered.   Examples  for  each  construct  will 
be  taken ^  whenever  possible,  from  the  semantic  description  of  DEMALGOL  I  given 
in  Appendix  D  and  discussed  in  Chapter  6. 

^.1  General  Structure  of  ISL 

Pure  ISL  constructs  (i.e.,  non-ALGOL)  may  be  classified  into  three 
general  categories:   ISL  declarations,  ISL  statements  and  ISL  operands.   ISL 
declarations  are  used  similarly  to  ALGOL  declarations  and  serve  mainly  to  declare 
the  ISL  data  structures:   stacks,  tables  and  cells.  Each  structure  must  be  de- 
clared before  it  can  be  used  in  a  statement  or  operand.   ALGOL  and  pure  ISL  de- 
clarations may  be  freely  intermixed  in  the  declaration  part  of  a  block  while 
ALGOL  and  pure  ISL  statements  and  operands  may  be  used  in  any  order  in  the  com- 
pound tail  of  each  block.   As  in  ALGOL,  no  declaration  is  allowed  among  the 
statements  (except  if  a  statement  is  a  block)  and  no  statement  is  allowed  among 
the  declarations.   It  is  easy  to  see  the  reasons  for  these  rules  if  one  considers 
that  ISL  statements  and  declarations  are  translated  into  ALGOL  statements  and 
declarations  and  a  valid  ALGOL  program  must  result.   The  ALGOL  rioles  about  use 
of  the  same  identifier  in  different  blocks  and  scope  of  each  declaration  also 
apply  to  ISL. 

Every  ISL  construct  is  characterized  by  the  character  "$"  immediately 
followed  by  the  name  of  the  construct  which  is  an  identifier  with  six  or  fewer 
characters.  When  the  construct  has  parameters,  they  must  appear,  enclosed  in 
parentheses,  following  the  $  <ISL  construct  identifier>  .  Moreover,  the  "$"  may 
never  be  in  the  first  column  of  a  card. 
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Every  ISL  program  must  r  tart  with  the  construct  $BEGIN  and  end  with 
$END.   These  replace  the  initial  BEGIN  and  final  END  of  an  ALGOL  program  and 
serve  as  markers  for  the  ISL  translator  to  begin  and  to  quit  translating.   Note 
that  $BEGIN  appears  only  at  the  beginning  of  the  program  and  $END  only  at  the 
end. 

An  ISL  program  is  the  semantic  description  of  one  pass  of  a  compiler 
for  a  given  language.   Thus,  the  complete  semantic  description  of  a  language  L 

I  to  be  implemented  with  an  n-pass  compiler  requires  n  ISL  programs,  one  for  each 
pass  (additionally,  if  n  >  1,  a  HEAD  containing  only  a  <list  of  declarations>  as 

j  defined  in  Appendix  A,  production  lo).  These  n  programs  can  be  fed  sequentially 
in  only  one  file  to  the  ISL  translator  or  the  TWINKLE  translator  as  described  in 
Chapter  5- 

4.1.1  The  Action  Label 

It  has  already  been  mentioned  in  Chapter  2  that  the  basic  semantic 
unit  is  the  semantic  action  or  semantic  routine  which  is  called  by  semantic 
action  calls  and  semantic  tests  in  the  syntax.   Therefore,  the  compound  tail  of 
the  main  block  of  an  ISL  program  is  divided  into  pieces  which  correspond  to  the 
semantic  actions.   Each  of  these  pieces  is  composed  of  one  or  more  statements 
and  is  identified  by  an  ISL  construct  called  action  label  which  is  used  just 
like  a  label  in  ALGOL  and  has  the  following  syntax: 

<action  label>  ::=  $ACTION  (<generalized  identifier>) 

;  where  a  generalized  identifier  is  an  identifier  in  which  not  only  letters  but 
I  also  digits  are  allowed  as  the  first  character.   Normally,  a  generalized  identi- 
fier appearing  in  an  action  label  must  have  appeared  somewhere  in  the  syntax  as 
I  the  name  of  a  semantic  action  in  a  semantic  action  call  or  semantic  test.   In 
general,  action  labels  do  not  have  to  be  declared  since  their  "declaration"  is 
provided  to  the  ISL  translator  by  the  TWINKLE  translator  via  the  file  ACTIONS. 
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An  action  label  must  precede  the  first  statement  of  each  semantic  action  and 
every  statement  in  an  ISL  program  must  belong  to  a  specific  semantic  action 
(except  if  the  statement  is  in  a  procedure  body  in  the  outermost  block).   The 
end  of  a  semantic  action  is  automatically  indicated  either  by  the  next  action 
label  or  by  the  $END.   Note  that  the  specifications  above  result  in  the  fact 
that  the  declaration  part  of  the  outermost  block  of  an  ISL  program  must  be  fol- 
lowed by  an  action  label.   Thus  the  appearance  of  the  first  action  label  marks 
to  the  translator  the  end  of  the  outermost  declaration  part.   This  is  important 
since  the  translator  must  know  that  point  and  can  find  it  without  an  extensive 
parsing  of  the  declarations.   Figure  13  presents  the  block  structure  of  a  typi- 
cal ISL  program. 
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Figure  13.   Block  structure  of  a  typical  ISL  program. 


59 

4.1.2  Semantic  Action  Zero 

The  name  "o"  (character  zero)  has  a  special  meaning  in  a  semantic 
action:   it  can  appear  in  an  action  label  in  an  ISL  program  but  it  cannot 
appear  in  a  semantic  action  call  in  the  syntax.   In  fact,  this  action  is  auto- 
matically called  by  the  parser  before  the  parsing  starts  at  each  execution  of 
the  compiler  (see  Figure  h   for  an  indication  of  where  action  0  is  called).   For 
pass  i  (i  >  l),  the  IL  recognizer  calls  action  0  before  starting  reading  the  IL 
string.   Therefore,  the  user  may  use  action  0  to  perform  all  initializations 
needed  in  the  semantic  variables,  tables,  stacks,  etc.   The  ISL  translator  also 
generates  some  variables  that  need  initialization;  for  each  table  or  stack  de- 
clared in  a  block,  a  pointer  is  created.   These  pointers  must  be  initialized  to 
zero  at  the  beginning  of  the  compound  tail  of  the  block  at  which  they  were  cre- 
ated.  For  the  outermost  block,  such  pointer  initialization  is  performed  in 
action  0.   Thus,  if  the  user  declared  an  action  0,  the  ISL  translator  introduces 
at  its  beginning  the  pointer  initializations.   If  the  user  did  not  use  action  0, 
the  ISL  translator  creates  one  as  the  last  non-empty  action  and  in  this  case  all 
it  contains  is  the  pointer  initializations. 

U.1.3  The  Structure  of  a  Translated  ISL  Program 

Some  considerations  about  the  code  generated  by  the  ISL  translator 
are  in  order  since  they  help  in  understanding  a  few  of  the  ISL  constructs. 
i;  Figure  ik   presents  the  block  structure  of  the  code  generated  by  the  ISL  trans- 
lator for  the  ISL  program  in  Figure  13  and  file  ACTIONS  as  in  the  upper  right 
j'  corner  of  Figure  ik.      First  of  all,  it  should  be  noticed  that  the  output  code 
j  is  not  a  complete  AlGpL   program;  it  consists  of  declarations  and  a  few  executable 
statements  at  the  end.   Thus,  in  Figure  k   the  output  of  the  ISL  translator  is 
not  only  the  semantics  package  but  also  the  language  assignments  and  the  call  to 
PARSE  and  PEED;  in  Figure  8,  the  output  of  the  ISL  translator  is  the  pass  i 
semantics  package  and  the  call  to  the  IL  recognizer.   Therefore,  the  executable 
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standard  declarations 


file  ACTIONS 


declaration  part 
^box  1  translated  to  ALGOL) 


action 
name 

action 

code  # 

B 

1 

XXX 

2 

A 

3 

XXX 

1+ 

C 
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XXX 

6 

• 
• 
• 

• 
• 
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PROCEDUEE  EXEC(N);   VALUE  N;    INTEGER  N; 
BEGIN 

LABEL  ACTIONA,    ACTIONB,    .    .    .    ,   ACTIONC,    ISLEND; 

SWITCH   ISLSWITCH:-^ACTI0N0,  ^ACTIONB,  ^CTIONXXX^^ACTIONA,^^ACTIONXXX,  ^  ACTIONC ,^ 


0 


1 


^ACTIOroOO^  .    .    .    j 
6 
GO  TO  ISLSWITCH   (N  +  l); 


ACTIONA: 


list  of  statements 

(box  2  translated  to  ALGOL) 


GO  TO  ISLEND^ 


ACTIONB: 


list  of  statements 

(box  3  translated  to  ALGOL) 


GO  TO  IS LEND; 


ACTIONC: 


list  of  statements 

(box  m  translated  to  ALGOL) 


GO  TO  ISLEND; 


ACTIONO: 


pointer  initializations 


GO  TO  IS  LEND; 

ACTIONXXX:   ACTIONXXX:  .  .  .  ACTIONXXX:   ISLEND; 
END  OF  PROCEDURE  EXEC; 


executable  part 


Figure  ih.      Block  structure  of  a  translated  ISL  program. 
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part  at  the  bottom  of  Figure  ik   c  )nsists  mainly  of  calls  to  the  IL  recognizer 
for  pass  i  (i  >  l)  and  of  calls  to  PARSE  and  FEND  for  pass  1.   The  declarations 
can  be  divided  into  three  parts: 

a)  a  group  of  standard  declarations  containing  variables^  procedures 
and  definitions  used  throughout  every  translated  ISL  code; 

b)  the  user's  declaration  part  which  is  simply  box  1  of  Figure  13 
with  the  ISL  declarations  translated  into  ALGOL  declarations; 

c)  procedure  EXEC(N). 

Procedure  EXEC  is  the  main  procedure  in  the  semantics  package  and  the 
parser  expects  EXEC  to  behave  in  the  following  way:  when  EXEC(n)  is  called, 
the  semantic  action  whose  code  number  is  n  must  be  executed,  and  no  other  state- 
ment should  be  executed.   Figure  1^  shows  clearly  how  this  is  accomplished  with 
the  aid  of  the  switch  ISLSWITCH.   One  ALGOL  label  is  generated  for  each  action 
name  by  concatenating  the  ACTION  name  to  the  identifier  ACTION.   Then  each  of 
these  labels  is  placed  in  switch  ISLSWITCH,  in  the  i-th  position  if  the  code  num- 
ber of  the  action  is  i.   All  over  Figure  1^  XXX  stands  for  other  action  names. 
In  this  example  it  was  assumed  that  the  user  did  not  use  action  0  in  the  seman- 
tics.  Therefore,  the  ISL  translator  introduced  it,  containing  only  pointer  ini- 
tializations, after  the  last  semantic  action.   Finally,  after  action  0  are 
placed  the  labels  corresponding  to  action  names  that  occurred  in  the  syntax  but 
did  not  occur  in  the  semantics  so  they  are  treated  as  empty  actions.   Note  that 
the  ISL  translator  has  only  one  pass,  so  ISLSWITCH  is  generated  based  only  on 
the  Information  present  in  the  file  ACTIONS  since  at  that  point  the  action  names 
that  will  appear  in  the  semantics  are  not  yet  known. 
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k.2     ISL  Declarations 

The  first  category  of  ISL  constructs,  ISL  declarations,  can  be 
loosely  divided  into  three  e;roaps: 

a)  data  struct-ure  declarations; 

b)  control  declarations; 

c)  define  declarations. 

Each  group  will  now  be  considered. 

U.2.1  Data  Structure  Declarations 

These  declarations  enable  the  user  to  establish  three  types  of  data 
structures  useful  in  the  description  of  semantics:  tables,  stacks  and  cells. 

U.2.1.1  Table  Declarations 

The  syntax  for  table  declarations  is  as  follows; 

<table  declaration>  ::=  $TABLE  (<list  of  table  specif ications>) 
<list  of  table  specif ications>  ::=  <table  specification>  | 

<list  of  table  specifications>  ; 
<table  specification> 
<table  specif ication>  ::=   <table  identifier>  ,  <nuraber  of  rows>  , 

<Iist  of  column  specifications> 
<list  of  coliimn  specif ications>  ::=  <coluiiin  specif ication>j 

<list  of  column  specifications>, 
<column  specification> 
<column  specif ication>  ::=  <col"uimi  identifier>  =  <left  bit  of  field> 

<bits  in  field> 
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A  table  is  a  structure  containing  rows  and  columns.   The  table  is 
designated  by  a  table  identifier  which  can  be  any  identifier  not  yet  declared 
in  the  block.   The  number  of  rows  must  be  an  unsigned  integer  and  each  row  is 
designated  by  an  Integer:  the  first  row  is  #0,   the  second  #1   and  so  on.   Each 
row  contains  a  certain  number  of  bits  (constant  for  all  rows  of  the  same  table) 
grouped  in  fields  called  columns.   Each  column  is  designated  by  an  identifier. 
No  two  columns  of  the  same  table  can  be  designated  by  the  same  identifier.   How- 
ever there  is  no  restriction  on  the  use  of  the  same  column  identifiers  in  dif- 
j f erent  tables,  even  when  they  are  declared  in  the  same  block.   The  field  associ- 
ated with  each  column  identifier  is  defined  by  a  pair  of  unsigned  integers 
separated  by  ": "  .   The  first  integer  indicates  the  number  of  the  first  bit  in 
the  field  and  the  second  integer  defines  how  many  bits  the  field  contains.   Bits 
are  numbered  from  left  to  right,  starting  with  0.   Thus  the  column  specification: 

LEVEL  =  32  :  ^ 

associates  with  the  column  LEVEL  the  ^-bit  field  starting  at  bit  #  32.   Each 
table  declaration  automatically  generates  a  declaration  of  an  integer  which  is 

I  reserved  as  a  pointer  to  the  rows  of  that  table.   The  identifier  of  the  pointer 

I 

■  of  a  table  is  formed  by  concatenating  the  identifier  PT  and  the  table  identifier. 

I  Thus  a  table  called  IDTAB  will  have  as  pointer  the  identifier  FTIDTAB.  The  pointer 

i 

I  of  a  table  may  be  used  or  set  by  the  user  and  is  also  automatically  used  and/or 

I 

updated  by  certain  ISL  constructs.   Moreover,  the  pointer  is  automatically  ini- 
tialized to  zero  as  explained  in  section  ^.1.2. 

!         Implementation  and  restrictions:   The  actual  implementation  of  ISL  in 
the  B-5500  machine  places  some  restrictions  on  the  coliimn  specifications. 

j  Tables  are  implemented  using  arrays  with  the  same  identifier  used  for  the  table. 

\  The  arrays  can  be  one,  two  or  three-dimensional.   Each  row  contains  (n  DIV  ^)  +1 
words  where  n  is  the  bit  number  of  the  rightmost  bit  used  in  any  column.   Since 
the  first  bit  (7^)  of  each  word  in  the  B-5500  is  not  accessible  to  the  user. 
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bits  -whose  number  1  is  such  that  (i  MOD  ^8)  =  0  may  not  be  used  in  any  columi. 
Tables  which  use  only  one  word  per  row  are  more  efficient  to  manipulate  than 
tables  with  multi-word  rows.   Also  tables  with  less  than  1023  rows  are  more 
efficient  to  manipulate  than  tables  with  more  than  1023  rows  since  these  are 
simulated  with  a  number  of  blocks  of  512  rows  each.  The   maximum  value  for  the 
number  of  rows  is  1023  X  512  =  523^776.   The  maximum  bit  number  that  can  be  in- 
cluded in  a  column  is  1023  X  kS   -  1  =  ^9^103.   The  column  structure  is  imple- 
mented by  emitting  a  number  of  BeA  defines,  one  or  two  per  column.   Tables  with 
single-word  rows  need  one  define  per  coliMm  and  the  identifier  of  the  define 
is  the  concatenation  of  the  table  identifier  with  the  column  identifier.   Besides' 
these  restrictions,  tables  with  multi-word  rows  need  one  more  define  per  column 
and  the  identifier  is  the  same  as  that  used  for  the  first  define  with  a  "Z" 
added  at  the  end.   Thus  a  column  named  TYPE  of  a  table  called  IDTAB  generates 
the  identifier  IDTABTIPE  if  IDTAB  has  one  word  per  row  and  the  identifiers 
IDTABTYPE  and  IDTABTYPEZ  if  IDTAB  has  two  or  more  words  per  row.   One  word  about 
error  detection  in  the  ISL  translator:   ISL  should  be  considered  a  2-pass  system, j 
the  first  pass  being  the  ISL  translator  and  the  second  pass  the  BeA  compiler. 
The  ISL  translator  only  detects  some  errors  which  are  in  the  ISL  constructs  them- 
selves but  no  ALGOL  parse  is  done  so  many  errors  are  found  only  at  BeA  compila- 
tion time. 

Example  of  a  table  declaration: 


$ TABLE  (IDTAB,  1022,  PTTOBIGTAB  =  1 

PTTOABTAB  =  2^ 
TYPE  =  36 
FOUm  =   39 

PTTOLKLIST  =  1+0 
LKLIST,  256,  PTTOABTAB  =  1 
BLOCKS TACK,  I6,  PTABTAB    =  1 


3  ,  BACKPT 

= 

Ik 

10  , 

8  ,  LEVEL 

= 

32 

^  . 

2  ,  USED 

= 

38 

1  , 

1  ,  LABFIELD 

= 

36 

^  . 

8  ,  REST 

= 

38 

10  ; 

8  ,  LIM 

= 

9 

8  i 

8  ,  PTLKLIST 

= 

9 

'     8  ) 
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This  declaration  defines  three  tables  called  IDTAB,  LKLIST  and  BLOCKSTACK. 
Figure  15  presents  the  structure  of  the  tables  obtained  with  this  declaration. 
Notice  that  column  fields  may  overlap.   For  example,  the  column  LABFIELD  of 
IDTAB  is  in  fact  the  union  of  the  columns  lYPE,  USED  and  FOUM);  the  column 
REST  of  IDTAB  is  the  union  of  the  columns  USED,  FOUT©  and  PTTOLKLIST.   Notice 
also  that,  although  more  than  one  table  may  be  declared  inside  the  parenthesis 
of  a  $TABIiE,  the  user  is  free  to  use  as  many  $TABLE  constructs  as  desired  in  the 
same  declaration  part. 

^.2.1.2  Stack  Declarations 

The  syntax  for  stack  declarations  is  exactly  similar  to  the  syntax  of 
table  declarations  except  that  no  <list  of  column  specifications>  appears  in  a 
stack  declaration.   In  fact,  stacks  are  basically  one-col"umn  tables,  i.e.,  tables 
in  which  one  word  is  allocated  for  each  row.   Therefore,  there  is  no  need  to  name 
this  one  column  of  a  stack.   Stacks  also  have  a  pointer  automatically  associated 
with  them  and  the  same  formation  rules  as  given  for  the  table  pointer  apply. 

In  the  B-5500  implementation,  each  position  (i.e.,  row)  of  a  stack  is 
a  ^-bit  word.   Like  tables,  stacks  with  less  than  102  3  positions  are  more  effi- 
cient to  manipulate  for  the  reason  already  explained  for  tables.   The  maximum 
/alue  for  the  nimber  of  rows  in  a  stack  is  identical  to  that  for  tables. 

Example  of  a  stack  declaration: 

$STACK  (IFSTACK,  32) 
The  structure  of  the  stack  thus  declared  is  presented  in  Figure  l6. 
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Figure  15-   Structure  of  the  tables  IDTAB,  LKLIST  and  BLOCKSTACK. 
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Figure  l6.   Structure  of  the  stack  IFSTACK. 

i4-.2.1.3  Cell  Declarations 

The  syntax  for  cell  declarations  is  similar  to  that  of  table  declara- 
tions, except  that  no  <nuniber  of  ro"ws>  appears  in  a  cell  declaration.   In  fact, 
cells  are  basically  one-row  tables.   Therefore,  cells  do  not  have  a  pointer 
associated  with  them.   Cells  are  useful  to  store  patterns  of  information  which 
will  later  be  entered  in  a  table  with  a  column  stinicture  equal  to  the  column 
structure  of  the  cell.   The  same  implementation  techniques  and  restrictions  men- 
tioned for  tables  apply  for  cells:   there  may  be  one-word  cells  and  multi-word 
cells  and  the  former  are  more  efficient  to  manipulate. 

Example  of  a  cell  declaration: 

$CELL  (LKLISTCELL,  PTTOABTAB  =1:8,  LINK  =9:8) 


This  cell  corresponds  to  one  row  of  the  table  LKLIST,  as  presented  in  Figure  15 . 
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4.2.1.4  The  Predefined  Data  Structurf-S  and  the  Add  Col-umn  Declaration 

Certain  tables  are  assumed  to  he  predefined  in  an  ISL  program  and 
the  user  does  not  have  to  (and  may  not)  declare  them.   They  are:  MSTACK  (for 
all  passes)  and  BIGTAB  (for  pass  1  only).   Therefore,  the  ISL  translator  he- 
haves  as  if  it  received,  at  the  beginning  of  each  program,  the  following  declara- 
tion (where  n  is  the  value  of  STACKSIZE): 

$TABIE  (MSTACK,  n,  LTYPE  =  1  :  5,  SEM  =  6  :  12, 

ENTRY  =  18  :  12,  TZPE  =  30  :  6,  ILENTRY  =  36  :  12; 
BIGTAB,  8192,  SEM  =  1  :  15,  WORDS  =  I6  :  3,  CHARS  =  I9  :  3, 
lEFTPT  =22  :  13,  RIGHTPT  =  35  :  13, 
CHART  =  12  :  6,  CHAR2  =  I8  :  6,  CHAR3  =  24  :  6, 
CHAR4  =  30  :  6,  CHAR5  =  36  :  6,  CHAR6  =  42  :  6) 

Figure  5  shows  the  structure  of  BIGTAB  and  Figure  7  the  structure  of  MSTACK. 

The  add  column  declaration  was  created  mainly  to  enable  the  user  to 
modify  the  column  structure  of  the  predefined  tables.   This  may  be  very  con- 
venient in  order  to  divide  the  semantic  field  (which  is  predeclared  simply  as 
SEM)  into  several  coliimns  or  to  associate  a  name  more  mnemonic  than  SEM.   Ob- 
viously the  user  cannot  introduce  these  modifications  in  the  ISL  declaration  of 
BIGTAB  and  MSTACK  because  such  declarations  do  not  appear  physically.   The  add 
column  declaration  then  may  be  used.   Syntactically,  the  add  column  declaration 
is  exactly  similar  to  a  cell  declaration.   The  identifier,  however,  may  be  either 
a  cell  identifier  or  a  table  identifier  provided  it  has  already  been  used  in  the 
corresponding  ISL  declaration  and  the  add  column  is  in  the  scope  of  the  "mother" 
declaration.   An  add  column  declaration  does  not  create  arrays  or  pointers:   it 
just  creates  the  BeA  defines  to  add  some  new  columns  to  the  column  structure 
already  in  effect  for  that  table.   Therefore,  add  column  declarations  are  sub- 
jected to  the  restriction  that  the  columns  being  added  cannot  require  a  greater 
number  of  words  per  row  than  the  number  already  allocated  to  the  table  or  cell 
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in  the  main  declaration.  Although  primarily  created  because  of  the  predefined 
tables,  add  column  declarations  may  be  used  for  any  cell  or  table  previously 
declared  and  any  number  of  these  declarations  may  modify  the  same  main  declara- 
tion. 

Example  of  an  add  coliomn  declaration: 

$ADDCOL  (BIG TAB,  PTTOIDTAB  =6  :  10,  MMBEROK  =  5:1; 
MSTACK,  PTTOIDTAB  =8  :  10,  MMBEROK  =  7  :  1  ) 

This  declaration  declares  two  new  coliomns  in  BIGTAB  and  MSTACK,  both  contained 
inside  column  SEM.   Figure  17  shows  the  new  structure  of  MSTACK  and  BIGTAB, 
after  being  modified  by  the  declaration  above. 

U.2.2  Control  Declarations 

These  declarations  are  mainly  concerned  with  providing  information 
for  the  ISL  translator  enabling  it  to  generate  correct  ALGOL  code. 

i+.2.2.1  Forward  Action  Declaration 

<forward  action  dfeclaration>  : :=  $FORWRD(<list  of  action  identifiers>) 

<list  of  action  identifier^  :  :=  <generalized  identifier>   | 

<list  of  action  identifiers>  <generalized  identifier> 

Sometimes,  it  is  possible  to  have  in  an  ISL  program  actions  which  are 
never  directly  referred  to  in  the  syntax.   Such  actions  are  named  "indirectly 
called"  and,  although  never  explicitly  executed  by  the  parser,  may  be  called 
from  other  semantic  actions,  by  means  of  the  ISL  execute  statement. 

The  purpose  of  the  forward  action  declaration  is  to  inform  the  ISL 
translator  of  the  future  appearance  of  indirectly  called  actions.   The  translator 
must  know  this  before  the  end  of  the  outermost  declaration  part  because,  as 
explained  in  Section  U.I.3,  ISLSWITCH  must  be  generated  containing  one  label 
for  each  action.   The  basic  source  of  information  for  this  is  the  file  ACTIONS, 
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Figure  17 .      BIGTAB  and  MSTACK  after  an  add  column  declaration. 
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but  it  does  not  contain  the  names  of  indirectly  called  actions  since  they 
never  appeared  in  the  syntax.   Therefore,  the  forward  action  construct  serves 
as  a  "declaration"  of  those  actions.   Obviously,  forward  action  declarations  must 
appear  only  in  the  outermost  declaration  part  or  else  it  is  too  late  for  the 
translator  to  use  the  information  they  provide. 

An  example  of  a  forward  action  declaration  is: 

$FOR¥RD   (22,  AUXIL) 

This  informs  the  translator  that  indirectly  called  semantic  actions  named  "22" 
and  "AUXIL"  occur  in  the  program. 

4.2.2.2  Number  of  Actions  Declaration 

<number  of  actions  declaration>  :  :=  $IJPPERN  (<unsigned  integer>) 

The  number  of  actions  declaration  is,  like  the  f onward  action  con- 
struct, related  to  providing  information  for  the  translator  to  build  ISLSWITCH. 
In  this  case,  however,  this  information  is  accepted  in  lieu  of  the  file  ACTIONS 
instead  of  in  addition  to  it. 

This  declaration  is  needed  only  when  there  is  no  file  ACTIONS  avail- 
able on  disk  at  the  time  of  the  ISL  translation.   This  might  be  the  case  when 
the  user  is  simply  debugging  the  semantics  rather  than  trying  to  create  a  com- 

'  piler.   The  unsigned  integer  in  the  declaration  must  then  be  equal  to  or  larger 

j 

j  than  the  total  number  of  semantic  actions  present  in  the  ISL  program.   The 

i  number  of  actions  declaration  enables  the  translator  to  create  a  dummy  ISLSWITCH 

!  that  allows  the  user  to  completely  check  the  syntax  of  the  resulting  ALGOL  code. 

I  Note,  however,  that  the  code  created  in  this  situation  cannot  be  used  in  the 

I  final  compiler  since  there  was  no  file  ACTIONS  available  to  provide  the  matching 

I 

1  of  semantic  action  calls  and  declarations.  When,  at  an  ISL  translation,  the 

:  file  ACTIONS  is  available,  the  number  of  actions  declaration,  if  present,  is 
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ignored.  As  with  forward  action  declarations,  number  of  action  declarations 
must  appear  only  in  the  outermost  declaration  part. 

An  example  of  a  number  of  actions  declaration  is: 

$UPPERN  (22) 

This  informs  the  translator  that  there  are  no  more  than  22  semantic  actions  in 
the  program  and  this  infomnation  should  be  used  to  create  a  dummy  ISLSWITCH  if 
the  file  ACTIONS  is  not  available. 

4.2.2.3  In  Declaration 

<in  declaratiori>  :  :=  $  IN  (<list  of  declarations>) 

The  purpose  of  this  construct  can  best  be  understood  by  referring  to 
Figure  l4.   There  one  can  see  that  all  declarations  in  the  outermost  declaration 
part  of  an  ISL  program  are  placed  (in  the  translated  ALGOL  code)  on  the  same 
level  as  the  declaration  of  procedure  EXEC,  rather  than  internal  to  it.   The 
reason  for  this  is  obvious:   if  the  declarations  were  local  to  procedure  EXEC 
then  their  contents  would  be  lost  each  time  EXEC  is  exited.   Naturally,  the 
user  usually  wants  the  contents  of  tables,  stacks,  etc.  to  be  conserved  between 
calls  of  semantic  actions.   Sometimes,  however,  it  is  necessary  to  insert  dec- 
larations local  to  procedure  EXEC:  labels  and  switches  to  be  used  in  the  semantic 
actions,  for  example,  must  be  declared  local  to  EXEC  due  to  BeA  restrictions. 
This  is  the  task  of  the  in  declaration.   The  <list  of  declarations>  given  as  a 
parameter  to  this  construct  consists  of  a  string  of  declarations  separated  by  ";" 
This  string  is  stored  in  a  buffer  and  is  later  output  local  to  procedure  EXEC, 
following  the  declaration  of  ISLSWITCH.   Obviously,  there  is  no  meaning  in  a 
nesting  of  in  declarations  so  the  <list  of  declarations>  must  not  contain  any 
$IN.  Like  the  two  previous  constructs,  the  in  declaration  must  appear  only  in 
the  outermost  declaration  part. 
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An  example  of  an  in  decxaration: 

$IN  (LABEL  LI  ,  L2  ;  SWITCH  S¥  ^  LI  ,  L2  ) 

The  result  of  this  construct  is  to  place  the  declarations  of  Ll^  L2  and  SW 
immediately  following  the  declaration  of  ISLSWITCH  and  thus  local  to  procedure 
EXEC. 

i|.2.2.4  End  of  Declarations  Declaration 
<end  of  declarations  declaration>  : :=  $ENDEC 

An  end  of  declarations  declaration  is  needed  to  mark  the  end  of  the 
declaration  part  of  all  inner  blocks  (i.e.;,  all  blocks  internal  to  the  outer- 
most) if  such  declaration  part  contains  at  least  one  table  or  stack  declaration. 
Although  superfluous,  an  end  of  declarations  declaration  may  also  be  present  in 
aJiy  other  block,  including  the  outermost.   Note,  however,  that  when  present 
the  $E1\IDEC  must  appear  as  the  last  declaration  just  before  the  beginning  of 
the  compound  tail.   The  purpose  of  $EKDEC  is  to  enable  the  ISL  translator  to 
output  initializations  of  table  and  stack  pointers  as  the  first  statements  of 
the  translated  compound  tail.  Without  the  $ENDEC  a  very  sophisticated  parsing 
would  be  needed  to  locate  the  beginning  of  the  compound  tail.  A  $EWDEC  is  not 
necessary  in  the  outermost  block  because  in  such  a  block  pointer  initializations 
are  inserted  as  the  first  statements  of  action  0  (see  Section  4.1.2)  and  not 
at  the  beginning  of  the  compound  tail. 

4.2.3  Define  Declarations  and  Definition  Calls 

These  constructs  provide  a  simple  macro-expander  facility.   The  define 
declaration  associates  strings  of  characters  with  certain  identifiers:   the 
defined  identifiers.   The  syntax  is  as  follows: 
<ISL  define  declaration>  : :=  ^DEFINE   (<ISL  definition  list>) 
<ISL  definition  list>  : :=  <ISL  definition  part> 

<ISL  definition  list>,  <ISL  definition  part> 
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<ISL  definition  part>  : :=  <ISL  defined  identifier>  =  <definition>  # 

where  a  definition  can  be  essentially  any  string  of  symbols  not  containing 

the  character  "#",  which  indicates  the  end  of  the  definition. 

An  ISL  define  declaration  does  not  cause  any  code  to  be  output;  it 
simply  tells  the  ISL  translator  to  store  the  string  of  symbols  and   associate 
it  with  the  defined  identifier.   These  identifiers  then  maybe  used  in  defini- 
tion calls  which  have  the  following  syntax: 

<definition  call>  : :=  $DF  <ISL  defined  identifier> 

In  the  production  above  the  defined  identifier  must  be  concatenated  to  the  $DF. 
A  definition  call  is  simply  replaced  at  translation  time  by  the  string  of  symbols 
that  has  been  associated  with  it  by  the  define  declaration. 

ISL  defines  are  basically  an  ISL  implementation  of  BeA  defines.   ISL 
defines  are  expanded  by  the  ISL  translator  while  BeA  defines  are  not  recognized 
by  the  translator  and  will  be  obeyed  only  by  the  BeA  compiler.   Therefore,  BeA 
defines  may  be  used  in  all  constructs  that  are  transparent  to  the  ISL  translator 
while  ISL  defines  must  be  used  in  constructs  that  will  be  parsed  at  ISL  trans- 
lation.  Obviously  the  user  might  use  only  ISL  defines  for  both  types  of  con- 
structs but  since  BeA  defines  are  more  convenient  to  use  than  ISL  defines,  he 
will  probably  use  these  only  when  the  former  would  not  work.   The  following 
example  presents  a  case  in  which  the  ISL  define  could  not  be  replaced  by  a  BeA 
define. 

Example  of  an  ISL  define  declaration: 

$DEFINE  (LKLISTROWS  =  256#, 

LKLISTCOLUMNS  =  PTTQABTAB  =  1:8;,  LINK  =  9:8#) 

This  definition  might  then  be  used  in  the  following  table  declaration: 
$TABLE  (LKLIST,  $DFLKLISTROWS ,  $DFLKLISTCOLUMNS ) 
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which  would  "be  equivalent  to  the  declaration  of  LKLIST  given  as  an  example 

in  Section  U. 2. 1.1. Note  that  there  is  no  restriction  to  the  nesting  of  defines, 

i.e.,  a  define  declaration  may  contain  definition  calls. 

U.3  ISL  Operands 

These  constructs  may  be  used  in  arithmetic  expressions  as  primaries 
and  enable  the  user  to  manipulate  tables,  stacks  and  cells.  Operands  are  the 
second  category  of  ISL  constructs  and  they  include  three  types  of  constructs: 

a)  the  ISL  operands; 

b)  pointer  operands; 

c)  search  operands. 

4.3.1  The  ISL  Operand 

This  is  a  generic  name  for  three  operands:   the  table  operand,  the 
stack  operand  and  the  cell  operand,  all  characterized  by  the  string  $OPD.   This 
is  by  far  the  most  common  and  useful  ISL  construct  and  simply  designates  one 
location  of  a  table,  stack  or  cell.   It  can  be  used  either  as  a  primary  in 
an  arithmetic  expression  or  as  the  leftmost  left  hand  side  of  an  assignment 
statement.   Used  as  a  primary,  a  $OPD  provides  the  value  currently  stored  in 
the  designated  element  of  the  table,  stack  or  cell.  As  a  left  hand  side  of  an 
assignment  statement,  it  allows  a  value  to  be  stored  in  the  designated  element. 

The  syntax  for  a  table  operand  is  as  follows: 

<table  operand>  ::=  $OPD  (<table  identifier>,  <row  information>, 

<coluran  information>) 
<row  information>  :  :=  <arithmetic  expression>  |  $WOW  |  $NEXT.  |  $  TOP  | 

$TOP  <adding  operator>  <arithmetic  expression> 
<column  informatiori>  : :=  <coluran  identifier>  |  $ALL  | 

$ALL  <arithmetic  expressiori> 
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In  order  to  designate  an  elament  of  a  table,  a  table  operand  must 
contain  3  pieces  of  information:   the  table  name  and  the  row  and  coliimn  of  the 
element.   Stack  and  cell  operands  are  exactly  similar  to  table  operands  except 
that  <column  information>  does  not  appear  in  a  stack  operand  and  <row  informa- 
tion>  does  not  appear  in  a  cell  operand.  Therefore  only  table  operands  will  be 
explained  in  detail.  M 

The  row  information  of  a  table  operand  may  contain  either  an  arith- 
metic expression  or  a  number  of  ISL  constructs. An  arithmetic  expression  appearing 
as  row  information  designates  simply  that  the  row  indicated  is  the  row  whose 
number  is  the  value  of  the  arithmetic  expression.   The  special  ISL  constructs 
present  an  automatic  way  to  make  reference  to  the  pointer  associated  with  the 
table.   In  ISL,  it  is  assumed  that  pointers  point  to  the  next  available  location 
of  a  table  or  stack. The  top  of  MSTACK,  for  example,  is  pointed  to  by  PTMSTACK-1. 
This  is  precisely  the  meaning  of  $TOP  as  row  information;  it  is  equivalent  to: 
PKtable  identifier>  -1.   $NOW  is  a  symonym  of  $TOP  kept  for  historical  reasons. 
$TOP  can  be  modified  by  an  arithmetic  expression  and  the  normal  use  of  this 
feature  is  to  indicate  the  positions  of  a  stack  or  table  relative  to  the  top. 
Thus  $TOP  -  1  points  to  the  first  position  below  the  top  and  is  equivalent  to 
PT  <table  identifier>  -  2.   Finally  $NEXT  indicates  the  next  available  row  and 
is  therefore  equivalent  to  PT  <table  identifier>.  j 

The  column  information  consists  normally  of  a  column  identifier       | 
indicating  in  which  column  the  designated  element  is  to  be  found.  j 

In  special  cases  $ALL, or  $ALL  followed  by  an  arithmetic  expression, 
may  be  used  as  column  information  to  indicate  that  the  column  is,  in  fact,  the 
whole  word.  $ALL  is  used  in  tables  with  one  word  per  row  and  is  equivalent  to 
a  column  defined  as  1:^7-  $ALL  followed  by  an  arithmetic  expression  must  be 
used  in  place  of  $ALL  for  tables  with  multi-word  rows.  The  value  of  the 
arithmetic  expression  indicates  which  of  the  words  of  a  row  is  to  be  picked. 
Thus  $ALL  3  designates  the  column  97 :hj ,    i.e.,  all  the  third  word  of  the  row. 
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Examples   of  table   operands: 

$opd(mstack,  $now,  entry) 

designates  the  location  on  top  of  MSTACK  (i.e.,  pointed  to  by  PTRSTACK-l), 
in  the  ENTRY  FIELD.   It  is  known  that,  for  an  identifier  on  top  of  MSTACK, 
the  contents  of  this  location  is  a  pointer  to  the  entry  of  the  identifier 
in  BIGTAB.   Therefore,  the  first  character  of  the  BCD  representation  of  the 
identifier  could  be  picked  up  by  the  following  operand: 

$OPD  (BIGTAB, $0PD(MSTACK, NOW, ENTRY)  +  1,  CHARl) 

Note  the  use  of  $OPD  in  the  row  information  of  another  $OPD.   This  is  very 
common  in  ISL  and  is  very  useful  in  following  a  structure  of  pointers  down  to 
several  levels  of  indirect  addressing. 

U.3.2  Pointer  Operand 

|,  <pointer  operand>  :  :=  $POINTER(<table  identifier>)  |  $POINTER(<stack  identifier>) 

A  pointer  operand,  which  may  be  used  as  a  primary  or  a  left  hand  side  of  an 
assignment,  yields  the  pointer  associated  with  the  table  or  stack;  i.e., 
PKtable  identifier>  or  PKstack  identifier>.   Since  it  is  easier  and  more 
efficient  to  use  the  name  of  the  pointer  directly,  this  construct  is  not 
normally  used,  although  it  can  make  an  ISL  program  a  little  more  readable  for 
a  user  unfamiliar  with  ISL. 

Example  of  a  pointer  operand: 

$POINTER(MSTACK) 

This  is  equivalent  to:   PTMSTACK 
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4. 3-3  Search  Operand 

This  operand  can  only  be  used  as  a  primary  in  arithmetic  expressions. 
There  are  2  types  of  search  operands:   stack  searchs  and  table  searchs.   Since 
the  stack  search  operand  is  similar  to  the  table  search  operand,  except  for 
the  absence  of  <column  informatiori>,  only  the  table  search  will  be  treated  here. 
The  syntax  for  a  table  search  operand  is  the  following: 

<table  search  operand>  : :=  $SEAECH(<table  identifier>, 

<colim]n  informatiori>, 
<arithmetic  expressiori>) 

This  operand  performs  a  sequential  search  on  the  table  specified, 
starting  at  the  current  top  of  the  table  (i.e.,  PT<table  identif ier>-l)  and 
going  down  (i.e.,  to  lower  numbered  rows)  by  successive  rows.   For  each  row, 
the  contents  of  the  field  designated  by  the  column  information  is  compared  with 
the  value  of  the  arithmetic  expression  which  is  the  3-rd  parameter  of  the  operand. 
The  operand  returns  the  row  number  of  the  first  row  for  which  the  comparison 
above  is  successful.   If  there  is  no  match,  the  value  returned  is  -1. 

Example  of  a  table  search  operand: 

$SEARCH ( MSTACK , TYPE , 3 ) 

The  value  returned  will  be  the  row  number  of  the  "first"  (in  the  sense  above) 
row  of  MSTACK  that  contains  a  string  (i.e.,  type  3)-   If  no  row  of  MSTACK  con- 
tains a  string,  the  value  returned  is  -1. 

h.k     ISL  Statements 

ISL  Statements  are  used  just  like  BeA  statements  and  provide  a  "higher 
level"  degree  of  manipulation  of  tables,  stacks  and  cells  as  compared  with  the 
manipulations  allowed  by  ISL  operands.   The  main  statements  enable  the  user 
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to  push  and  pop  stacks  or  tables,  enter  information  in  a  table  or  cell  and 
to  emit  intermediate  code.   There  are  also  the  increment  and  decrement  state- 
ments and  the  execute  statement.   Each  statement  is  now  individually  analyzed. 

4.4.1  Increment  and  Decrement  Statements 

<increment  statement>  : :=  $INCR(<leftmost  left  part>) 

<decrement  statement>  : :=  $DECR(<leftmost  left  part>) 

where  a  leftmost  left  part  is  any  construct  allowed  as  the  leftmost  left  hand 

side  of  an  assignment  statement.   These  statements  simply  generate  code  to  add 

one  to  the  leftmost  left  part  ($INCR)  or  to  subtract  one  from  it  ($DECR). 

Although  they  perform  a  trivial  task,  they  can  contribute  to  the  readibility 

of  an  ISL  program. 

Example : 

$incr(ptabtab) 

which  is  equivalent  to: 

PTABTAB  -  PTABTAB  +  1 

k.k.2     Execute  Statement 

<execute  statement>  : :=  $EXEC(<generalized  identifier>) 

The  purpose  of  this  statement  is  to  allow  the  user  to  request,  in 
a  given  semantic  action,  the  execution  of  another  action  whose  name  is  the  only 
parameter  of  the  construct.   Thus,  if  an  action  called  "22"  contains  a  subset 
of  what  must  be  done  in  action  "7",  there  is  no  need  to  repeat  "22"  in  "7"; 
at  the  appropriate  point  in  "7",  "22"  may  be  called  for  execution  with  the 
following  statement: 

$EXEC(22) 
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The  same  effect  could  be  obtained  with  procedures  (and,  in  fact,  $EXEC  simply 
causes  a  recursive  call  of  the  procedure  EXEC)  but  the  use  of  $EXEC  seems  to  be 
simpler  and  more  natural. 

4 . U . 3  Push  and  Pop  Statements 

These  dual  statements  allow  manipulation  of  information  in  a  row  of  a 
table  or  stack  with  automatic  adjustment  of  the  pointer.  For  both  statements 
there  is  a  table  form  and  a  stack  form.   Since  stack  pushes  and  pops  are  a 
trivial  simplification  of  table  push  and  pop  statements,  only  the  latter  will  be 
considered  here.   The  syntax  for  stack  push  and  pop  statements  is  presented  in 
Appendix  A,  productions  62  and  67- 

<table  push  statement>  : :=  $PUSH(<table  identifier>,<entry  list>) 
<entry  list>  : :=  <entry  element>  |  <entry  list>,  <entry  element> 
<entry  element>  : :=  <column  informatiori>  :  <arithmetic  expression> 
<table  pop  statement>  : :=  $POP(<table  identifier>,  <pop  entry  list>)  | 

$POP(<table  identifier>) 
where  a  pop  entry  list  is  exactly  similar  to  an  entry  list  except  that  instead 
of  arithmetic  expressions  the  pop  entry  list  must  contain  leftmost  left  parts. 

The  effect  of  a  $PUSH  is  the  following:   the  next  available  row 
in  the  table  (which  is  pointed  to  by  the  pointer  associated  with  the  table) 
is  taken  and  the  field  corresponding  to  each  column  information  in  the  entry    | 
list  is  iniatilized  to  the  value  of  the  arithmetic  expression  that  follows  the 
column  information.  Any  field  not  referred  to  by  the  entry  list  is  left 
unchanged.   Then  the  pointer  associated  with  the  table  is  incremented  to  point 
to  the  next  row. 

A  $POP  is  essentially  the  dual  of  a  push  statement.   Its  effect  is 
the  following:   the  present  top  row  of  the  table  (which  is  pointed  to  by 
PKtable  identif ier>-l)  is  taken  and  each  leftmost  left  part  in  the  pop  entry 
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list  is  initialized  to  the  value  stored  in  the  field  referred  to  by  the  column 
information  that  precedes  the  left  most  left  part.  Then  the  pointer  associated 
with  the  table  is  decremented  to  point  to  the  row  just  used.   Notice  that  no 
information  is  erased  from  the  table,  but  the  row  is  now  marked  as  available 
and  eventually  will  be  overwritten. 

There  is  one  simple  form  of  $POP  which  does  not  contain  a  pop  entry 
list.   The  effect  of  this  is  simply  to  decrement  the  pointer. 

Examples  of  push  and  pop  statements: 

(a)   $PUSH(rDTAB,PTTOBIGTAB  :  TEMP2,  BACKPT  :  TEMPI, 

PTTOABTAB   :  PTABTAB,  LEVEL  :  CULEVEL, 
TYPE  :  STORETYPE,  REST:  O) 

which  is  equivalent  to  the  following  compound  statement: 

BEGIN 

$0PD(IDTAB,PTIDTAB,PTT0BIGTAB)  *-  TEMP2; 
$0PD(IDTAB,PTIDTAB, BACKPT  )  ^  TEMPI) 
$0PD(IDTAB,PTIDTAB,  PTTOABTAB  )  *-   FTABTAB; 

$opd(ldtab,ptidtab,  level  )  *-  culevel; 

$opd(ldtab,ptidtab,type  )  *-  storetypej 

$opd(idtab,ptidtab,rest  )  ^  o; 
$incr(ptidtab) 

END 


(b)   $POP(irffAB) 
which  is  equivalent  to  $DECR(PTIDTAB) 

k.k.h     Enter  Statement 


The  enter  statement  is  a  generalization  of  the  table  push  statement 
and  is  used  to  initialize  several  columns  of  a  cell  or  a  row  of  a  table  with 
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only  one  statement.   Consequently,  there  is  a  table  enter  statement  and  a 
cell  enter  statement.   Because  of  similarities  between  these,  only  table  enter 
statements  will  be  discussed  here. 

<table  enter  statemenl>  : :=  $ENTER(<table  identifier>, 

<row  information>, 
<entry  list>) 

The  effect  of  a  $ENTER  statement  is  precisely  the  same  as  the  effect 
of  a  $PUSH  except  for  the  two  following  differences: 

a)  instead  of  always  picking  the  next  available  row  of  the  table, 
the  enter  statement  utilizes  the  row  designated  by  the  row 
information; 

b)  no  pointer  increment  is  performed  by  an  enter  statement.  i 

Example  of  an  enter  statement : 

Renter (IDTAB, TEMPI, PTTOLKLIST  :  PTLKLIST-1,  USED  :  l) 
which  is  equivalent  to  the  following  compound  statement: 

BEGIN 

$0PD(IDTAB, TEMPI, PTTOLKLIST)  *-   PTLKLIST-1; 

$0PD(IDTAB, TEMPI, USED)  ^  1 
END 

U.U.5  Code  Statement 

<code   statement>    :  :=  $CODE(<list   of  operators   and  operandi) 

<list   of  operators   and  operands>    :  :=  <operand>     |   <operator>     ( 

<list   of  operators   and  operands>,<operand>[ 
<list   of  operators   and  operands>,<operator> 

<operand>    : :=  <arithmetic  expression> 
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<operator>  : :=  <static  operator>  |  <dynamic  operator> 

<static  operator>  : :=  *   <generalized  identifier> 

<dynamic  operator>  :  :=  #  <arithinetic  expression> 

The  $CDDE  statement  provides  output  of  IL  operators  and  operands.   Each  element 

in  the  list  of  operators  and  operands  causes  the  writing  of  one  element  in  the 

intermediate  language  string. 

If  the  element  is  an  arithmetic  expression,  an  IL  operand  will  be 
emitted.   The  rightmost  l6  bits  of  the  value  of  the  expression  are  taken  as 
the  IL  element.  A  check  is  performed,  however,  to  assure  that  an  IL  operand 
will  result:   field  32:U  of  the  value  of  the  expression,  which  will  be  the  IL 
table  number,  is  tested  and,  if  0,  is  replaced  by  a  1.   Thus  if  the  user  tried 
to  output  an  operand  with  a  table  number  =  0  (which  would  make  it  an  operator), 
a  table  number  =  1  is  arbitrarily  inserted. 

If  the  element  of  the  list  of  operators  and  operands  is  an  arithmetic 
expression  preceded  by  the  character  "#",  then  an  IL  operator  will  be  emitted. 
The  rightmost  12  bits  of  the  value  of  the  expression  are  taken  as  the  IL  entry 
and  the  IL  element  is  completed  with  the  addition  of  a  table  number  field  =  0, 
thus  making  sure  that  an  IL  operator  will  result.   Note  that  the  arithmetic 
expression  that  defines  the  operator  is  evaluated  each  time  the  $CODE  statement 
is  executed  in  a  semantic  routine.   Therefore,  the  operator  emitted  may  depend 
on  a  dynamic  condition  such  as  the  situation  of  MSTACK.   In  fact,  this  is  one  of 
the  most  common  uses  of  a  dynamic  operator  as  shown  by  the  following  example: 

$C0DE(#$0PD(MSTACK,PTMSTACK-2, entry) ) 

This  statement  emits,  when  executed,  an  IL  operator  whose  code  number  (i.e., 
the  IL  entry  number)  is  equal  to  the  current  value  of  the  entry  field  in  TOP-1 
of  MSTACK.   Therefore,  the  same  statement  could  be  used  to  emit  code  when  any 
1  of  the  following  productions  is  reduced: 


<BOOLEAN  EXPRESSIOK> 
<BOOLEAN  TERM> 
<TERiy> 
<TERM> 
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=  <BOOLEAN  EXPRESSIOII>  #0R  <BOOLEAN  TERMS> 

=  <BOOLEAN  TERM>  #AWD  <BOOLEAN  PRIMARl^ 

=  <TERiy!>  X  <ARITHMETIC  PRIMA.RY> 

=  <TERM>  /  <ARITHMETIC  PRIMARY> 
The  operator  emitted  would  be  different  in  each  case  and  equal  to 
the  code  number  associated  with  the  terminals  "AND",  "OR",  "x"  and  "/",  respec- 
tively (see  Section  2.2.1.1  for  an  explanation  of  the  assignment  of  code  num- 
bers to  terminals) .   It  is  known  that  each  semantic  action  has  a  code  number 
associated  with  it.   Thus,  if  the  code  numbers  of  the  semantic  actions  in 
pass  2  were  equal  to  the  code  numbers  associated  by  the  scanner,  an  automatic 
"linking"  would  result,  i.e.,  only  one  code  statement  in  pass  1  semantics 
allows  the  system  to  execute  in  pass  2  one  of  four  pass  2  semantic  actions 
named:   "AND",  "OR",  "x" ,  and  "/".   This  also  is  the  reason  for  allowing,  as 
semantic  action  names  strings  containing  one  single  character.   The  way  pro- 
vided for  automatic  linking  of  terminal  code  numbers  with  pass  i  (i>l)  semantic 
action  code  niombers  will  be  described  as  static  operators  are  explained. 

If  an  element  of  the  list  of  operators  and  operands  is  a  generalized 
identifier  preceded  by  the  character  "*"^  then  an  IL  operator  will  be  emitted. 
In  this  case,  however,  the  operator  emitted  will  always  be  the  same  for  every 
execution  of  the  code  statement.   This  is  why  this  type  of  operator  emission  is 
called  static. 

EXAMPLE:  #C0DE(*GETSPACE) 

This  statement  emits  an  IL  operator  containing  as  entry  number  a  code  number 
associated  (by  the  ISL  translator)  with  the  operator  named  "GETSPACE"-   The 
method  used  to  associate  this  code  number  is  the  following:   The  ISL  trans- 
lator keeps  a  table  called  SPSTAB  which  contains  a  list  of  generalized 
identifiers  and  associated  code  numbers.   This  table  is  initialized, 
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at  the  beginning  of  the  ISL  translation,  according  to  the  setting  of  the  option 
SPSTAB  which  is  described  in  Chapter  5*   Thus,  when  a  static  operator  is  foiind, 
the  operator  name  is  looked  up  in  SPSTAB.   If  fo\ind,  the  associated  code  number 
is  picked  and  emitted  as  the  entry  field  of  the  operator.   If  not  found,  the 
operator  name  is  entered  in  SPSTAB  and  the  next  available  code  niiraber  is  asso- 
ciated with  it;  then  the  IL  operator  is  emitted.   Therefore,  at  the  end  of 
the  pass  i  semantics  translation,  an  updated  SPSTAB  is  available  and  is  used 
to  generate  two  files  which  may  be  utilized  by  the  semantics  of  the  next  pass: 
the  files  ACTIONS!  and  OPRTABi  .   Thus,  for  pass  i  (i>l),  the  file  ACTIONS  needed 
by  the  ISL  translator  is  provided  by  translation  of  the  previous  pass  while  for 
pass  1  it  is  provided  by  the  TWINKLE  translator.   The  complete  file  structure 
is  detailed  in  Chapter  5- 

The  method  provided  for  linking  terminal  code  numbers  with  semantic 
action  code  numbers  is,  thus,  automatically  provided  by  one  setting  of  the 
SPSTAB  option  which  causes  SPSTAB  to  be  initialized  with  the  list  of  terminal 
names  and  their  code  numbers. 
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5.   USE  OF  THE  I3L  TRANSLATOR 

This  chapter  is  dedicated  to  describing  details  of  the  actual  use  of 
the  ISL  translator.   Besides  a  description  of  the  file  structure  and  instruc- 
tions for  running  the  translator^  it  contains  a  detailed  discussion  of  its  con- 
trol cards  and  control  options.   A  good  understanding  of  ISL  control  options  is 
essential  to  obtaining  the  full  advantage  of  the  automation  that  they  provide. 

5.1  The  File  Structure 

For  a  description  of  the  set  of  files  used  by  the  ISL  translator,  it 
must  be  initially  remarked  that  files  on  the  B-5500  disk  are  characterized  by 
a  pair  of  identifiers  (each  with  no  more  than  seven  characters)  separated  by  a 
slash: 

<f ile  narae>  : : =  <pref ix>  /  <suf f ix> 

In  the  implementation  of  a  given  language  with  the  system,  a  name 
must  be  picked  for  the  language.   The  language  name  (henceforth  called  £.n.)   is 
input  to  both  the  TWINKLE  and  ISL  translators  and  all  the  files  created  by  the 
system  for  that  language  will  have  a  name  of  the  form:  <£.n.>  /   <suffix>  . 
Thus  several  different  languages  implemented  on  the  system  may  coexist  on  the 
B-5500  disk. 

5.1.1  Block  Diagram 

Figuj'e  18  presents  a  diagram  of  all  the  files  that  may  be  involved  in 
an  ISL  translation.   It  is  assumed  that  the  semantic  program  being  translated 
is  the  description  of  pass  i.   The  following  is  a  discussion  of  each  file  in- 
dicated in  Figure  I8. 
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<i.n.>/SEMA.WT 


if  i=l:    <i.n.>/TABLESF 
[if  i>l    :<i.n.>/OPRTA£i 


<i.n.>/ACTIONi 


initialization  of 


SPSTAB 


Pass  i 


ISL 
Translator 


SPSTAB 


--.  C_|i 


line  printer  listing 


( 


if  i  =  0    :  <^.n.>/ALGHMD 
if  i  >  0    :  <i.n.>/ALGSMi 


<i.n.>/ZIPDECK 


<i.n.>/ACTION  (i+1^ 


<i.n.>/OPRTAB  (i+l) 


Figure  l8.      Diagram  of  the  files  used  by  the  ISL  translator. 
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SEMANT: 

This  is  the  primary  input  file  for  the  ISL  translator.   It  contains 
the  source  code  in  ISL  card  images  as  well  as  control  cards.   The  structure  of 
the  file  SEMANT  is  illustrated  in  Figijire  I9.   There  one  can  see  that  SEMMT  is 
in  fact  composed  of  a  number  of  semantic  programs,  each  identified  "by  the  option 
PASSNIMBER  (see  section  5.3.^)-   Obviously,  for  the  translation  of  pass  i  only 
the  semantic  program  identified  as  PASSNIMBER  i  is  taken  as  input.   For  i  =  0, 
SEMANT  is  the  only  input  file  used  and  its  PASSNUMBER  0  must  be  an  ISL  program 
containing  only  a  list  of  declarations  (i.e.,  the  compound  tail  of  the  outermost 
block  must  be:   $END).   Also  the  only  file  generated  is  <i.n.>  /  ALGHEAD. 

OPRTABi : 

This  file  basically  contains,  in  a  binary  tree  structure,  the  action 
names  present  in  the  file  ACTIONi.   It  is  used  to  allow  efficient  lookup  of  the 
action  names.   For  i  =  1  this  tree  is  in  the  table  OPRTAB  of  the  file  TABLESF. 
Thus  TABLESF  is  used  in  this  case. 

ACTIONi : 

This  file  contains  a  list  of  action  names  and  the  associated  code  num- 
bers.  Note  that  for  i  =  1  the  suffix  ACTIONS  is  used  in  lieu  of  ACTIONI.   Also, 
for  i  =  1,  the  names  correspond  to  semantic  action  calls  found  in  the  syntax  and 
the  file  is  created  by  the  TWINKLE  translator.   For  i  >  1,  the  names  correspond 
to  IL  operators  found  in  $CODE  statements  in  the  previous  pass  and  the  file  is 
created  by  the  ISL  translation  of  such  previous  pass. 

initialization  of  SPSTAB: 

SPSTAB  (see  section  k.k.'^)    can  be  initialized  in  a  number  of  different 
ways,  depending  on  the  setting  of  the  option  SPSTAB  as  described  in  section  5* 3. 6. 


file  SEMANT 
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$#  MJMBEROFPASSES  n 
M  PASSNUMBER  0 


ISL  program  containing  the  HEAD 


$#  PASSNUMBER  1 


ISL  program  describing  the 
semantics  of  pass  1 


absent  if 
n  =  1 


PASSMJMBER  i 


ISL  program  describing  the 
seman.tics  of  pass  i 


$#  PASSMMBER  n 


ISL  program  describing  the 
semantics  of  pass  n 


Figure  19 .   Structure  of  the  file  SEMAIW. 
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line  printer  listing: 

If  the  proper  option  is  set  (see  section  5- 3.2)  the  ISL  translator 
outputs  a  listing  containing,  side  by  side,  the  source  cards  and  the  corres- 
ponding output  cards.   Appendix  E  presents  a  sample  of  such  a  listing. 

ALGSEMi : 

This  is  a  file  of  BeA  card  images  containing  the  result  of  the  trans- 
lation.  The  structure  of  this  file  is  detailed  in  Figure  lU.   Note  that,  for 
i  =  0,  the  suffix  ALGHEAD  is  used  in  lieu  of  ALGSEMO.   Also,  the  structure  of 
ALGHEAD  is  much  simpler  than  the  structure  of  ALGSEMi;  ALGHEAD  is  a  straight 
translation  of  HEAD,  without  the  addition  of  any  declarations. 

ZIPDECK: 

This  file  is  created  when  the  option  SAVEZIPDECK  is  set.   See  section 
5.3.5  for  a  description  of  ZIPDECK. 

ACTION  (i  +  1)  and  OPRTAB  (i  +  l): 

At  the  end  of  the  translation,  SPSTAB  contains  the  names  of  the  opera- 
tors found  in  $CODE  statements  and  their  respective  code  numbers.   This  informa- 
tion is  used  to  generate  the  files  OPRTAB  and  ACTION  for  the  next  pass,  i.e., 
OPRTAB  (i  +  1)  and  ACTION  (i  +  l). 

It  should  also  be  noticed  that  the  file  OPRTABi,  besides  being  used  at 
the  translation  of  pass  i,  is  also  needed  at  compile  time  if,  at  pass  i,  the 
IL  is  to  be  listed.   This  allows  the  printing  of  the  name  of  each  IL  operand, 
thus  making  debugging  much  easier. 

5.1.2  Selection  of  the  Input  File 

It  has  already  been  mentioned  that  the  file  ACTIONS  (i.e.,  ACTION  for 
pass  1)   is  built  by  the  TWINKLE  translator  and  contains  basically  a  list  of  the 
semantic  action  names  that  appeared  in  the  syntax  along  with  their  code  nvimbers. 
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In  addition  to  this,  two  other  pieces  of  information  may  also  be  present  in 
ACTIONS : 

a)  TWINKLE  allows  the  ISL  code  for  an  action  to  be  placed  in  the  syn- 
tax itself,  following  the  action  call.   These  actions  are  called 
intrinsic  actions  and  the  code  that  defines  them  is  put  in  the 
file  ACTIONS  following  their  names  and  code  numbers. 

b)  As  described  in  section  2.3.2,  the  user  may  decide  to  input  the 
semantic  description  of  the  language  (i.e.,  the  file  SIMANT)  to 
the  TWINKLE  translator,  following  the  syntactic  description.   The 
semantics  is  then  placed  at  the  end  of  the  file  ACTIONS,  as  a  tail 
to  it. 

Therefore,  the  ISL  translator  must  decide  whether  to  read  directly  its 
main  input  file  (SEMANT)  or  whether  to  take  it  from  the  tail  of  ACTIONS.   Also 
the  code  describing  intrinsic  actions  must  be  removed  from  ACTIONS  and  inserted 
in  SEMANT  at  the  appropriate  place.   Figure  20  shows  how  these  decisions  are 
taken. 

5.2  Running  the  Translator 

This  section  contains  specific  instructions  about  how  to  run  the  ISL 
translator  on  the  B-5500.   Initially,  one  should  keep  in  mind  that  the  trans- 
lator can  be  run  in  two  different  ways:   directly  or  indirectly.   Each  of  these 
is  now  described  separately. 

5.2.1  Indirect  Run 

This  type  of  run  is  obtained  when  the  user  specifies,  using  TWINKLE 
control  options,  that  he  wants  the  TWINKLE  translator  to  automatically  initiate 
the  ISL  translator.   The  way  to  specify  this  is  described  by  Mercer  [3].   In 
this  mode  the  TWINKLE  translator  communicates  the  i.n.  to  the  ISL  translator. 
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START  ISL  translation 


There  must  be  a  file  labeled  SEMA.NT. 
It  is  taken  as  the  input  to  the  trans- 
lator. However,  this  is  a  debugging 
run  only  and  PASSNUMBER  1  must  contain 
a  $l]PPERN  declaration. 


Take  the  tail  of 
<^.n.>/ACTIONS  as 
the  input  to  the 
t  mnslator. 


1 


There  must  be  a 
file  labeled  SEMAKT. 
It  is  taken  as  the 
input  to  the  trans- 
lator. 


I 


If  <i.n.>/ACTIONS  has  any  code 
for  intrinsic  actions,  insert 
this  code  on  the  input  file, 
just  before  the  end  of  PASS- 
NUMBER  1. 


Figure  20.   Flow  diagram  of  the  selection  of  the  input  file. 
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If  all  the  files  expected  by  the  CSL  translator  are  available,  the  user  does 
not  have  to  interfere. 

5.2.2  Direct  Rim 

For  debugging  the  semantic  programs  it  may  be  more  convenient  to  run 
the  ISL  translator  directly.   This  can  be  done  by  submitting  to  the  B-5500,  one 
of  the  control  decks  illustrated  in  Figure  21.   Note  that  in  this  case  the  user 
must  communicate  i.n.  to  the  ISL  translator.   This  is  done  by  means  of  the  first 
identifier  in  the  COMPILE  card.   The  second  identifier  is  completely  irrelevant 
and  is  only  used  in  the  heading  of  the  listing  produced  by  the  translator.   Note 
also  that  either  the  word  LIBRARY  or  the  word  SYNTAX  must  be  present  at  the  end 
of  the  COMPILE  card.   The  normal  mode  of  operation  is  with  the  word  LIBRARY. 
SYNTAX  is  used  for  syntax  checks  only  and  no  result  whatsoever  is  kept  on  disk 
in  this  type  of  run. 

5.3  ISL  Control  Cards  and  Control  Options 

Control  cards  may  appear  at  any  place  in  the  input  string  for  the  ISL 
,  translator.   They  are  completely  free-field  except  for  a  "$"  in  coliomn  1  and  a 
"#"  in  column  2.   Blanks  (one  or  more)  should  be  used  as  separators  between  the 
options.   There  is  no  provision  for  continuation  control  cards.   In  the  improb- 
able case  in  which  all  the  desired  options  do  not  fit  on  one  card  (columns  up  to 
71  can  be  used)  a  new  control  card  can  be  submitted  containing  the  remaining 

i  options.   There  is  no  limit  on  the  number  of  ISL  control  cards  used.   Each  con- 

j 

I  trol  card  affects  only  the  options  explicitly  mentioned  in  it,  "all  the  other 

I 

[    ,  .        .  . 

options  remaining  unchanged. 

ISL  control  cards  can  be  syntactically  described  as: 

t 

I  <ISL  control  card>  ::=  <ISL  control  card  prefix>  | 

<ISL  control  card>  <option> 


9k 


a)   File  SEMMT  is  on  cards 


?USER  -  <-user  code>  ^ 

/  SYNTAX 

?COMPII£     <:g.n.>/<ldentlfier>  WITH  ISL  ■/ 

I  LIBRARY 

?DATA  CARD  ^ 


deck  of  cards   containing 
the   file   SEMANT 


?END 


b)  File  SEMAM'  is  on  disk  under  the  name  <prefix>/<suffix> 


?USER  =  <user  code>  ^ 

/syntax 

?C0MPIIF;     <i.n.>/<identifier>  WITH  ISL    < 

j LIBRARY 
?ISL  FILE  CARD   =  <pref ix>/<suf fix>  SERIAL 

?END 


c)      File   SEMANT  is  the   tail  of  <i.n.>/ ACTIONS 


?USER  =  <-user   code>  ^ 

J  SYNTAX 

?COMPILE  <i.n.>/<identifier>  WITH  ISL  / 

^  LIBRARY 

?END  ^ 


Fie;-ure  21.   Control  decks  for  direct  runs  of  the  ISL  translator. 
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<ISL  control  card  pref ;:.x>  ::=  (dollar  sign  ("$")  and  sharp  sign  ("//") 

in  colimns  1  and  2  of  the  card,  res- 
pectively] 

Options :   Only  the  first  five  characters  of  an  option  identifier  are  analyzed 
by  the  ISL  translator  so  any  option  identifier  containing  more  than  five  charac- 
ters can  "be  trxmcated  to  its  first  five  characters. 

<option>  ::=  LANGUAGE  <string>  |  VERSION  <-unsigned  integer>  | 

LIST  I  NOLIST  I  ALGSEMLISTONLY  |  NOALGSEMLISTONLY  | 
COMPLIST  I  ALLIST  |  SEQ  <sequence  parameter s>  |  NOSEQ  | 
NEWSEQ  I  NONEWSEQ  |  SUBINC  <-unsigned  integer>  | 
NUMBEROFPASSES  <unsigned  integer>  | 

PASSNUMBER  <unsigned  integer>  <-where  it  is>  |  USEIL  | 
NOUSEIL  I  TEST  |  SPECIAL  <list  of  special  parameters>  | 
SAVEZIPDECK  <where  to  save>  |  INTERPRETIVE  | 
SPSTAB  <spstab  parameter> 

<sequence  parameter s>  ::=  <empty>  |  <unsigned  integer>  | 

+  <iinsigned  integer>  | 
<unsigned  integer>  +  <-unsigned  integer> 

<where  it  is>  ::=  <empty>  |  ONDISK  |  ONDISK  :  <prefix>  /  <suffix> 

<list  of  special  parameters>  ::=  <special  parameter>  | 

<list  of  special  parameters>  , 
<special  parameter> 

<special  paraiiieter>  ::=  SCANNER  |  PARDl  |  FILLTAB  |  PARD2  |  PBEGIN  | 

PEND  I  LK  I  FPI  I  FPF  |  ILRECOG 

<where  to  save>  : : =  DISK  I  PUNCH 
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<spstab  parameter>   ::=  EMPTY    |    CHARACTERS    |    TERMINALS    |    OPRTAB    | 

ONDISK 

5.3.1  The  Language  Options 

Two  options  fall  in  this  group:   LANGUAGE  and  VERSION.   Compilers 
created  by  the  system  print  a  heading  line  on  the  listings  containing  the  fol- 
lowing information: 

XXXXXXXXKXXX  COMPILER  -  VERSION  n  -  <date  and  hour> 

The  option  LANGUAGE  provides  a  way  for  the  user  to  specify  what  he  wants  printed 
in  place  of  the  string  of  X's  above.   The  contents  of  the  string  that  follows 
the  option  are  picked  out  as  the  characters  to  be  printed  in  the  heading.   The 
string  may  contain  up  to  twelve  characters;  if  it  contains  less,  they  are  right 
justified  in  a  field  of  blanks. 

Example:   LANGUAGE  "DEMALGOL  -  l" 

Default:   The  language  name  known  by  the  ISL  translator  (see  section 
5.2). 

The  option  VERSION  provides  a  way  to  insert  the  integer  n  that  is 
printed  in  the  heading. 

Example:   VERSION  2 

Default:   VERSION  1 

5.3.2  The  Listing  Options 

This  group  includes  the  following  options:   LIST,  NOLIST,  ALGSEMLIST- 
ONLY,  NOALGSEMLISTONLY,  COMPLIST  and  ALLIST.   The  discussion  of  the  last  two 
will  be  postponed  until  section  5«3.5' 
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Options  LIST  and  NOLIST: 

These  options  set  ON  or  OFF,  respectively,  the  Boolean  variable  LLIST 
which  controls  listing  on  the  line  printer.   If  LLIST  is  OFF,  no  listing  will  be 
performed  on  the  line  printer.   However,  if  an  ISL  error  is  found  and  LLIST  is 
OFF,  an  error  message,  the  last  card  read,  and  the  contents  of  the  output  buffer 
will  be  printed.   If  LLIST  if  ON,  system  messages  and  the  output  cards  (i.e., 
ALGSEM)  will  be  listed.   The  input  cards  will  also  be  listed  if  ALGSEMLISTONLY 
is  not  set. 

Default:   LIST 

Options  ALGSEMLISTONLY  and  NO ALGSEMLISTONLY: 

These  options  set  ON  or  OFF,  respectively,  the  Boolean  variable 
LISTOUTONLY.   If  LLIST  is  OFF,  the  state  of  LISTOUTONLY  is  irrelevant.   If  LLIST 
is  ON  and  LISTOUTONLY  is  OFF,  a  complete  listing  will  be  output  containing  sys- 
tem messages,  input  and  output  cards.   If  LLIST  is  ON  and  LISTOUTONLY  is  ON,  the 
input  cards  will  not  be  listed  and  the  rest  of  the  listing  remains  unaffected  by 
the  state  of  LISTOUTONLY. 

Default:   NOALGSEMLISTONLY 

5.3'3  The  Sequencing  Options 

These  options  are  related  to  assigning  a  sequence  number  to  the  cards 
of  ALGSEM.   They  include:   SEQ,  NOSEQ,  NEWSEQ,  NONEWSEQ  and  SUBINC. 

Options  SEQ,  and  NOSEQ,: 

These  options  set  ON  or  OFF,  respectively,  the  Boolean  variable  SEQ 
which  controls  the  assignment  of  sequence  numbers  to  the  card  images  in  ALGSEM. 
If  SEQ  is  OFF,  the  sequence  field  (columns  73  -  8o)  of  the  card  images  will  be 
left  blank.   If  SEQ  is  ON,  the  sequence  field  will  be  filled  with  a  sequence 
number.   The  value  of  this  sequence  number  is  determined  by  the 
<sequence  parameters>  which  may  follow  the  identifier  SEQ,  by  the  value  of 


I 


98 

SUBINC,  by  the  sequence  niunber  in  the  last  input  card  read  and  by  the  state 
(ON  or  OFF)  of  NEWSEQ. 

If  KEWSEQ  is  OFF,  the  sequence  number  of  an  output  card  image  will  be 
the  sequence  number  of  the  last  input  card  read.   However,  when  several  output 
cards  are  generated  after  the  reading  of  only  one  input  card,  the  first  output   ■ 
card  will  have  the  same  sequence  number  as  the  input  card,  say  m.   The  second 
output  card  will  have  the  sequence  number  m  +  SUBINC  .  .  .  the  n-th  output  card  I 
will  have  the  sequence  number  m  +  (n  -  l) SUBINC.   No  test  is  performed  to  pre- 
vent assigning  the  same  sequence  number  to  more  than  one  output  card;  however, 
since  it  is  extremely  improbable  that  more  than  a  few  dozens  of  output  cards  are 
generated  without  reading  a  new  card,  one  can  be  reasonably  sure  than  no  dupli- 
cate sequence  number  will  be  obtained  if  SUBINC  is  small  (say  1  or  2)  and  the 
input  cards  are  sequenced  with  a  large  increment  (say  lOO). 

If  NEWSEQ  is  ON,  the  sequence  field  of  the  input  cards  is  irrelevant 
and  sequence  numbers  will  be  assigned  to  the  output  cards  as  follows:   The  first 
sequence  number  will  be  the  value  of  the  integer  variable  INITIALCARDNUMB  and  the 
increment  will  be  the  value  of  the  integer  variable  INC.   Both  INC  and  INITIAL- 
CARDNUMB are  initially  set  to  100.   These  values  can  be  modified,  if  desired,  by 
using  a  non-empty  sequence  parameter  part  after  the  identifier:   SEQ.   A 
sequence  parameter  part  containing  only  an  unsigned  integer  will  set  INITIAL- 
CARDNUMB to  the  value  of  that  integer.   A  sequence  parameter  part  containing 
+  <unsigned  integer>  will  set  INC  to  the  value  of  the  integer.   Finally,  a  se- 
quence parameter  type  of  the  form:  <uiisigned  integer>  +  <unsigned  integer>  will 
set  both  INITIAI^ARDNUMB  to  the  value  of  the  first  integer  and  INC  to  the  value 
of  the  second  integer. 

Default:   SEQ  100  +  100 
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Options  NEWSEQ  and  NOKEWSEQ: 

These  options  set  ON  or  OFF,  respectively,  the  Boolean  variable 
NEWSEQ  whose  role  has  been  described  above. 

Default :   NONEWSEQ 
Note  that  when  NEWSEQ  is  OFF  (as  in  the  default  setting),  the  card  images  in 
SEMMT  are  expected  to  have  a  sequence  nianber,  as  described.   If  the  se- 
quence field  of  a  card  in  SEMANT  is  blank,  the  sequence  number  00000000  will  be 
assumed. 

Option  SUB INC: 

This  option,  which  must  be  followed  by  an  unsigned  integer,  sets  the 
value  of  the  variable  SUBINC  to  the  value  of  the  unsigned  integer.  The  use  of 
SUBINC  was  described  previously. 

Default:   SUBINC  1 

5.3'^  The  Multi-pass  Options 

These  options  are  related  to  regulating  the  generation  of  multi-pass 
compilers.   They  are:   NUMBEROFPASSES,  PASSNIMBER,  USEIL  and  NOUSEIL. 

Option  NUMBEROFPASSES: 

This  option  defines  the  integer  that  must  follow  it  as  the  number  of 
passes  used  by  the  compiler.   It  is  mainly  used  for  checking  purposes  and  to 
decide  whether  or  not  there  must  be  a  file  <i.n.>  /  HEAD.   The  translator  ex- 
pects to  find  this  file  on  disk  when  NUMBEROFPASSES  is  greater  than  one  and  the 
first  semantic  program  input  to  the  compiler  had  a  non-zero  PASSNUMBER. 

Example:   NUMBEROFPASSES  3 

Default:   NUMBEROFPASSES  1 
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Option  PASSMJMBER: 

PASSMMBER  assigns  the  integer  that  must  follow  it  as  the  niunber  of 
the  next  semantic  program  to  he  input  to  the  translator.   If  MMBEROFPASSES  >  1, 
PASSEIMBER  0  means  the  HEAD.   In  an  indirect  run,  all  passes  must  be  present  in 
sequence.   Therefore,  the  first  semantic  program  is  assumed  to  be  #0,  and  so  on 
in  sequence.   If  PASSMMBER  options  are  present,  they  are  used  Just  as  a  check. 
In  direct  riins,  the  option  PASSKUMBER  is  followed  blindly  and  it  is  the  responsi- 
bility of  the  user  to  "label"  each  semantic  program  with  the  correct  PASSMMBER 
option.   If  the  word  ONDISK  follows  the  integer  in  a  PASSMMBER  option  it  indi- 
cates that  the  corresponding  program  is  on  disk  (under  the  name  <prefix>  / 
<suffix>)  Instead  of  being  the  next  set  of  cards.   The  translator  will  then  read 
the  program  from  disk.   If  no  <prefix>  /  <suffix>  follows  the  word  OWDISK,  the 
following  names  are  expected  in  the  disk  files:   for  PASSMMBER  0,  <f..n.>  /  HEAD; 
for  PASSMMBER  i  (i  >  O),  <£.n.>  /   SEMAUTi. 

Example:   PASSMMBER  2 

Default:  As  explained  above. 

Options  USEIL  and  NOUSEIL: 

The  option  USEIL  must  be  used  whenever  an  IL  string  is  created  in  a 
given  semantic  program.  This  option  guarantees  that  the  IL  file  will  be  kept 
on  disk  for  the  next  pass  of  the  compilation.  No  file  of  IL  will  be  saved  on 
disk  if  the  option  NOUSEIL  is  in  effect. 

Example :   USEIL 

Default :   NOUSEII 

5.3«5  The  Zipping  Options 

These  options  are  related  to  the  automatic  initiation  of  the  BeA  com- 
piler to  compile  the  compiler.   The  verb  ZIP  is  used,  in  the  B-5500  system,  to 
denote  the  initiation  of  one  program  by  another  and  will  be  used  here  with  this 


meaning.   It  has  been  mentioned  in  Chapter  2  that  the  ISL  translator  mounts  the 
ALGOL  source  for  the  compiler  by  putting  together  several  pieces  of  ALGOL  code. 
These  pieces  are  detailed  in  Figure  10.   The  ISL  translator  perfoi:Tns  this  mount- 
ing by  constructing  a  file  with  "calls"  to  the  appropriate  pieces  of  code  and 
submitting  this  file  (called  ZIP  file)  to  the  BeA  compiler  by  means  of  a  ZIP 
statement.   The  ALGOL  compiler  understands  these  calls  and  picks  the  pieces  out 
itself.   Tiro  different  types  of  calls  are  used  in  the  ZIP  file.   The  first  type 
is  of  the  form: 

$$  C  <piece  name> 

where  the  piece  name  is  an  identifier.   This  type  of  call  is  used  to  extract  the 
pieces  of  code  from  the  TWS  Symbolic  Library.   For  instance^  the  call 

$$  C  SCAMER 

inserts  the  SCANTIER  taken  out  of  the  TWS  Symbolic  Library  which  is  kept  on  the 
B-5500  disk  under  the  name  IWS/FILES.  The   second  type  of  call  is  of  the  form: 

$$  D  <prefix>  /  <suffix> 

and  causes  the  insertion  of  the  disk  file  named  <prefix>  /  <sufflx>  .   This  type 
of  call  is  used  to  place  the  language -dependent  parts  like  the  files  <i.n.>  / 
ALGSEMl  .   It  is  now  possible  to  understand  Figure  22,  which  presents  the  ZIP 
deck  in  detail.   Notice  that  the  form  of  the  ZIP  deck  depends  on  the  combination 
of  executable  and  interpretive  pieces  required  by  the  user.   This  information  is 
j  fed  via  TWINKLE  control  options  and  is  kept  on  TABLESF  from  where  it  is  picked 
out  by  the  ISL  translator  when  it  is  time  to  build  the  ZIP  deck. 

Option  TEST: 

This  option,  when  set,  inhibits  the  zipping  to  the  BeA  compiler  at  the 
end  of  an  ISL  translation.   Once  this  option  has  been  set,  there  is  no  provision 


102 


?  COMPILE  <i . n . >/DISK  ALGOL  LIBRARY 

?ALG0L  FILE  CASTC  -  TWS/FILES  SELIALjDATA  CARD 

■ -BEGIN 

$$   C   GLOBAL 
$$  D  <i.n.>/ALGHEAD 
-BEGIN 
$$   C   SCANNER 
$$   C   PARIDEC 


if  int.    FP:  DEFINE  IFP  =  TRUE  #; 

if  ex.    -FP:  DEFINE  IFP  =  FALSE  #; 

n_f  int.    LK:  DEFINE  IIK  =  TRUE  #; 

Af  ex.      IK:  DEFINE  ILK  =  FALSE  #; 


/if  int.    FT: 
Vif  ex.      FT: 

$$   C   PAR2DEC 

$$  C  PBEGIN 

$$   C   PEND 

J  if  int.    LK: 
Uf  ex.      LK: 

/if  int.    FP: 
Aif  ex.      FP: 


C  FILLTAB 

D  <i.n.>/FILLTAB 


C   LK 

D  <i.n.>/LK 

C  FPI 
C  FPE 


I  if  int.    FP:     blank  card 

\if  ex.      FP:      $$  D  <i.n.>/PARSER 

$$  D  <i.n.>/ALGSEMl 
-END 
-  -BEGIN 

$$   C   IIRECOG 

$$  D  <f.n.>/ALGSEM2 

$$  D  <^.n.>/ALGSEMn 
-^ND 
--END. 

?END 


/^int. 


ex. 


int. 


ex. 


int, 


ex. 


,  FP  means  interpretive 
FP  package 

FP  means  executable  FP 
package 

,  LK  means  interpretive 
procedure  LK 

LK  means  executable 
procedure  LK 

.  FT  means  interpretive 
procedure  FILLTAB 

FT  means  executable 
procedure  FILLTAB 


Figure  22.   The  ZIP  deck  for  the  compilation  of  the  compiler. 
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to  reset  it.   Note  that  the  zipping  is  also  inhibited  if  any  errors  have  been 
detected  by  the  ISL  translator. 

Default:   TEST  not  set  (i.e.,  the  system  will  try  to  zip  to  the  BeA 
compiler) . 

When  the  zipping  is  performed,  the  compilation  will  run  under  the  name 
ALGOL/<£.n.>   and,  if  successful,  will  enter  on  disk  the  file  <^.n.>/DISK  which 
is  the  final  product  of  the  system.   Instructions  about  its  use  are  given  in  [k]. 
Note  that,  although  it  is  always  the  ISL  translator  that  creates  the  ZIP  file, 
it  does  not  always  perform  the  ZIP.   In  fact,  when  executable  pieces  are  used, 
the  ALGOL  Code  Generator  must  create  those  pieces  and  the  zip  is  then  performed 
(with  the  ZIP  deck  created  by  the  ISL  translator)  either  by  the  ALGOL  Code  Gener- 
ator or  by  the  ISL  translator,  whichever  finishes  last. 

Option  INTERPRETIVE: 

This  option,  when  set,  causes  the  ISL  translator  to  ignore  the  informa- 
tion in  TABLESF  about  which  pieces  are  executable  and  to  create  a  ZIP  deck  for 
all  interpretive  pieces.   This  is  useful  when  one  is  simply  trying  to  deb-ug  the 

I 

semantics  and  the  executable  pieces  are  not  available.   Once  this  option  has  been 

set,  there  is  no  provision  to  reset  it. 

I  Default:   INTERPRETIVE  not  set. 

ii 

Option  SAVEZIPDECK: 

When  a  zip  is  performed  with  the  ZIP  deck,  the  deck  is  automatically 

I  removed  from  disk.   If  the  user  wants  to  save  a  copy  of  the  ZIP  deck  for  future 

^  direct  use,  he  can  set  the  option  SAVEZIPDECK  and  the  deck  will  be  saved:   on 

li 

'  disk  under  the  name  </..n.>/ZIPDECK  if  <where  to  save>  is  DISK*  and  on  punched 
cards  if  <where  to  save>  is  PUTTCH. 

Default:   SAVEZIPDECK  not  set. 


Option  SPECIAL: 

The  system  normally  uses,  for  the  non-language -dependent  pieces,  its 
own  standard  files  which  are  kept  in  the  TWS  Symbolic  Library.   However,  some- 
times the  user  needs  special  features  in  one  or  more  of  these  pieces  and  cannot 
use  the  standard  ones.   In  this  case  the  option  SPECIAL  should  be  used;  it  means 
that  the  system  will  pick  each  piece  listed  in  the  <list  of  special  paranieters> 
out  of  disk,  under  the  name  <^.n.>/<piece  name>.   Thus  the  option  SPECIAL  re- 
places $$  C  <piece  name>  calls  by  $$  D  <i.n.>/<piece  name>  .   It  is  the  user's 
responsibility  to  provide  the  special  pieces  (which  usually  are  the  standard  ones 
with  minor  additions  and  modifications)  and  insert  them  on  disk.   Once  SPECIAL 
has  been  set,  there  is  no  provision  to  reset  it. 

Default:   SPECIAL  not  set. 

Options  COMPLIST  and  ALLIST: 

These  options  are  related  to  listing  during  the  ALGOL  compilation  of 
the  compiler.   In  this  compilation,  listing  is  always  turned  off  for  all  blocks 
except  the  ALGSEM  blocks,  since  these  are  the  only  parts  the  normal  user  might  be 
interested  in  listing.   Listing  of  the  ALGSEM  blocks  only  can  be  turned  on  by 
means  of  the  option  COMPLIST.   In  the  event  complete  listing  of  the  compilation 
is  desired,  the  option  ALLIST  can  be  used.   Once  either  of  these  options  is 
turned  on,  there  is  no  provision  to  turn  it  off.   Note,  however,  that  listing  of 
parts  of  ALGSEMi  can  be  obtained  using  ALGOL  $  cards  in  the  semantic  programs 
since  these  cards  are  recognized  and  passed  to  ALGSEMi  at  ISL  translation  time. 
ALGOL  $  cards  may  also  be  introduced  anywhere  in  the  ZIP  deck. 

Both  COMPLIST  and  ALLIST  turn  on  not  only  the  listing  but  also  the 
printing  of  the  PRT  locations. 

Default;         COMPLIST  off  and  ALLIST  off  (i.e.,  no  compilation 

listing  at  all  will  be  provided). 
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5.3-6  The  Option  SPSTAB 

This  option  provides  a  choice  between  five  different  types  of  initi- 
alization performed  on  SPSTAB,  whose  role  was  explained  in  section  h.k.^.      Each 
SPSTAB  parameter  is  now  discussed: 


EMPTY:  No  initialization  is  performed  in  SPSTAB,  therefore  the  first  IL 
operator  will  receive  code  number  0,  the  second  code  number  1  and 
so  on.   This  parameter  is  used  when  no  dynamic  IL  operators  have 
been  emitted  with  $CODE  statements  thus  no  linkage  is  needed  with 
the  code  numbers  of  the  IL  operators. 
CHARACTERS:   SPSTAB  is  initialized  with  the  character  set  and  their  internal 

code  numbers.   This  is  useful  when  dynamic  IL  operators  expect  to 
find  only  characters  as  actual  parameters. 
TERMINALS:   SPSTAB  is  initialized  with  the  complete  set  of  terminals  and  their 
code  numbers.   This  parameter  is  probably  the  most  useful  since  it 
provides  the  linkage  between  terminal  code  n\;unbers  and  semantic 
action  code  numbers  mentioned  in  section  k.h.^.      The  data  for  this 
initialization  is  obtained  from  the  table  SPSTAB  of  TABLESF. 

OPRTAB:   Picks  OPRTABi  (for  pass  i)  as  the  initial  setting  of  SPSTAB.   This 
permits  a  "growing"  linkage:   in  each  pass,  the  code  number  of  an 
IL  operator  will  be  the  same  as  the  code  number  associated  with  an 
IL  operator  with  the  same  name  at  any  other  pass. 

ONDISK:   For  special  pu2rposes,  the  user  might  provide  his  own  initialization 
of  SPSTAB.  With  this  parameter,  SPSTAB  will  be  initialized,  in 
pass  i,  with  the  contents  of  the  file  <^.n.>/SPSTABi  which  is  ex- 
pected to  be  on  disk. 
Default:   SPSTAB  TERMINALS 
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6.   USE  OF  ISL  -  M   EXAJ^LE 

This  chapter  is  devoted  to  the  use  of  ISL,  i.e.,  how  to  describe 
the  semantics  of  a  programming  language  in  ISL.  Some  general  guidelines  are 
initially  presented  but  the  most  important  part  is  the  analysis  of  an  example. 

6.1  General  Considerations 

Obviously,  no  fixed  rules  may  be  given  about  how  to  use  ISL  to 
describe  the  semantics  of  a  language;  ISL  is  only  a  tool  and  the  ingenuity  of 
the  programmer  plays  a  very  important  part  in  determing  how  complete  and  effi- 
cient a  semantic  description  is.   Some  guidelines,  however,  are  presented  in 
this  section. 

The  task  of  describing  the  semantics  of  a  language  for  the  ILLIAC  IV 
TWS  may  be  divided  into  four  parts: 

a)  divide  the  Semantics  into  Passes:  As  explained  in  Section  2.1.2, 
it  is  left  to  the  user  to  decide  how  many  passes  will  be  em- 
ployed in  the  implementation  of  a  given  language.   It  is  also 
quite  important  to  decide  how  much  will  be  done  in  each  pass, 
trying  to  avoid  "crowding"  one  pass.   Section  2.1.2  also 
presented  guidelines  about  what  should  be  done  in  each  pass. 
Finally,  if  more  than  one  pass  is  used,  the  repertoire  of  IL 
operators  for  each  pass  must  be  selected. 

b)  plan  the  structure  of  each  pass:   In  this  part  the  user  should 
decide  which  tables,  stacks,  etc.  are  needed  in  each  pass.   The 
column  structure  of  the  tables  should  be  defined,  keeping  in 
mind  which  pointers  are  needed  and  how  many  bits  should  be  re- 
served for  each  of  them.   In  pass  1,  it  is  also  necessary  to 
decide  what  use  will  be  made  of  the  SEM  fields  of  BIGTAB  and 
MSTACK.   For  ALGOL-like  languages  it  is  classical  to  have,  in 
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pass  1,  a  table  of  d.3clared  identifiers  linked  with  forward 
and  backward  pointers  to  BIGTAB.   It  is  also  very  common  to  have 
a  stack  to  keep  track  of  the  block  structure  (levels)  of  the 
ALGOL-like  program.   Finally,  one  should  decide  in  this  part 
which  information  must  be  transferred  between  passes  and  plan 
the  structure  of  the  HEAD, 
c)   assign  semantic  calls  to  the  syntax:  Usually  the  syntax  is 
debugged  first  and  in  this  process  the  user  may  discover  the 
need  for  some  semantic  tests.   These  are  then  the  first  semantic 
calls  attached  to  the  syntax  and  may  indicate  the  need  to  keep 
some  table  or  stack  to  provide  the  information  required  to  "help" 
the  parser.   Then  the  semantic  action  calls  are  attached  to  the 
syntax  according  to  the  structure  chosen  for  the  first  pass. 
The  syntactic  preprocessor  then  should  be  used  again  to  make 
sure  that  the  addition  of  some  semantic  call  did  not  make  the 
syntax  unacceptable  by  the  Floyd  Productions  Generator.   On 
assigning  semantic  calls  to  the  syntax,  one  should  keep  in  mind 
the  rules  given  in  Section  2. 3*2.1  about  the  situation  of  MSTACK 
at  each  point  in  the  parsing.   The  purpose  of  the  semantic  calls 
is  to  transfer  control  to  the  semantic  routines  when  tables  must 
be  updated  and/or  IL  code  has  to  be  emitted.  However,  it  should 
be  noted  that,  in  general,  it  is  better  to  postpone  a  semantic 
action  call  as  much  as  possible;  i.e.,  insert  a  semantic  action 
call  only  when  the  next  reduction  would  cause  the  loss  of  necessary 
information.   In  this  way  the  user  may  have  only  a  few  calls  and 
do  a  lot  of  things  in  each  of  them,  rather  than  having  many  simple 
actions  which  would  cause  frequent  interruptions  in  the  parser. 
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d)  Write  the  semaxitic  actions  for  each  pass:   Once  the  previous 

three  parts  have  been  taken  care  of,  this  should  be  a  relatively 
straightforward  task.   The  only  care  would  be  to  use  ISL  as 
efficiently  as  possible. 

6.2  Analysis  of  the  Semantic  Description  of  DEMALGOL  I 

DEMAiGOL  I  is  an  extremely  simple  subset  of  ALGOL  which  has  been 
implemented  with  the  ILLIAC  IV  TWS  as  an  example.   DEMALGOL  I  has  no  arrays, 
procedures  or  repetitive  statements.   There  are  only  two  types  of  quantities: 
integer  and  boolean.  All  labels  must  be  declared  in  the  innermost  block  in 
which  they  occur.   There  are  only  three  basic  statements:   assignments,  go  to's 
and  if's.   IF  statements  must  be  complete  (i.e.,  there  must  always  be  an  ELSE 
part)  and  may  be  nested.   Blocks  may  also  be  nested  as  usual  in  ALGOL  and  the 
meaning  of  "scope"  of  a  declaration  is  retained. 

The  syntax  of  DEMALGOL  I  has  been  written  in  TWINKLE  in  two  different  1 
ways.  Appendix  B  contains  the  syntax  of  DEMALGOL  I  in  BNF  TWIMLE  productions 
only.  Appendix  C  contains  the  same  syntax  but  making  use  of  the  English- 
like constructs  available  in  TWIMLE.   Normally,  references  will  be  made  to 
Appendix  B;  Appendix  C  will  be  used  as  an  example  of  how  to  attach  Syntax  to 
the  English-like  constructs  of  TWINKLE.   Each  of  the  foiir  basic  parts  pointed 
out  in  Section  6.1  is  now  discussed  for  the  semantic  description  of  DEMALGOL  I. 

6.2.1  Dividing  the  Semantics  into  Passes 

Since  DEMALGOL  is  a  very  simple  language,  one  cannot  see,  a  priori, 
any  necessity  for  optimization  passes.   Thus,  DEMALGOL  will  be  implemented 
using  the  basic  number  of  passes  in  the  system,  i.e.,  2  passes.   The  next 
decision  must  be  the  repertoire  of  IL  operators  to  be  used  in  pass  2.  Following 
the  guideline  of  dealing  with  the  language  in  pass  1  and  with  the  machine  in 
pass  2,  the  set  of  IL  operators  listed  in  Table  5  'was  selected.   These  operators 
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seem  to  be  general  enough  to  be  nachlne  independent  and  should  enable  the 
generation  of  efficient  machine  code  for  almost  any  simple  computer.   Note,  how- 
ever, that  all  the  complexities  of  the  language  were  dealt  with  in  pass  1: 
block  structure,  nesting  of  if  statements,  linked  lists  of  forward  references, 
etc.   The  remainder  of  the  example  contains  only  the  implementation  of  pass  1 
which  is  obviously  the  most  complex  in  this  case.   The  IL  operators  have  been 
chosen  in  such  a  way  that  pass  2  can  be  quite  trivial  for  a  0  address  machine 
(stack  machine)  and  still  reasonably  simple  for  a  1  address  machine-   There 
are  some  considerations  about  a  possible  implementation  of  pass  2  for  a  stack 
machine:  this  implementation  is  so  simple  that  the  only  information  that  must 
be  passed  between  passes  is  in  the  IL  string;  therefore,  HEAD  may  be  empty  ex- 
cept perhaps  for  the  integer  MAXPTABTAB  which  contains  the  maximum  number  of 
work  area  locations  needed  in  pass  2.   Although  not  essential,  this  informa- 
tion might  make  pass  2  more  efficient  by  allocating  dynamically  the  size  of  the 
work  area  according  to  the  value  of  MAXPTABTAB-   This  work  area  is  the  only  non- 
simple  data  structure  in  pass  2:   It  might  easily  be  implemented  with  a  stack, 
and  the  contents  will  be  absolute  addresses  as  described  in  Table  5*   Most  IL 
operands  are  pointers  to  locations  of  the  work  area  and  only  the  entry  field 
of  IL  operands  is  used  since  there  was  no  need  for  more  than  one  table 

(in  fact,  stack)  in  pass  2-   For  a  stack  machine,  the  operators:  STORE,  +, 
-,  X,  /,  <,  >,  >,  <,  =,  =!=,  A-OT),  OR  are  all  trivially  implemented  since  the 
stack  automatically  stores  partial  results.   GETSPACE  and  FORGETSPACE  are  the 
storage  allocation  routines-   It  is  also  assumed  for  simplicity  that  the  code 
generated  is  kept  in  core,  disk  or  other  storage  with  random  access  so  that  the 
instructions  SETAJDDRUTRANSF  and  SETADDRCTRANSF  have  access  to  any  transfer 
instruction  previously  generated  in  order  to  set  the  addresses  of  forward 
references . 
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TABLE  5 
IL  OPERATORS  FOR  DEMALGOL  I 


I 


OPERATOR 
NAME 


pass  2  pass  2 

MS TACK  MS TACK 

BEFORE  AFTER 


GETSPACE 


D,C,B,A|       ...Dj 


FORGE TSPACE 


c,b,aI 


STORE 


D,C,B,A| 


c,b,a| 


c,b,a| 


X 

/ 

AND 

OR 

> 


■  D 


C,B' 


C,B' 


...C,B,A| 

...C,B' 

. . .c,b,a| 

...C,B' 

...C,B,A 

•  •  •  C  ^  B 

...C,B,A 

...C,B' 

...c,b,a| 

•  • . C  ^B 

DESCRIPTION 


Assign  memory  space  to  a  quantity  of 
type  B  (2  =  booleanj  3  =  integer), 
initialize  it  to  A  and  fill  the  loca- 
tion pointed  to  by  C  with  the  absolute 
address  of  the  space  assigned. 

Return  the  space  whose  absolute  address 
is  in  a  location  pointed  to  by  B  and 
which  was  utilized  by  a  quantity  of      i 
type  A. 

Emit  code  to  Store  the  quantity  whose 
address  is  pointed  to  by  C  into  the 
location  whose  address  is  pointed  to 
by  B;  the  quantity  is  of  type  A. 

Emit  code  to  Add  the  quantities  whose 
addresses  are  pointed  to  by  B  and  A; 
push  in  MS TACK  a  pointer  to  the  address 
of  the  result:  B'. 

Emit  code  to  Subtract  the  quantity  whose 
address  is  pointed  to  by  A  from  the  quan- 
tity whose  address  is  pointed  to  by  B; 
push  in  MSTACK  a  pointer  to  the  address 
of  the  result:  B'. 

as  above  but  Multiply. 

as  above  but  Divide. 

as  above  but  And. 

as  above  but  Or. 

Emit  code  to  Compare  the  quantity  whose 
address  is  pointed  to  by  B  with  the  quan- 
tity whose  address  is  pointed  to  by  A  for 
greater  than.   Push  in  MSTACK  a  pointer 
to  the  address  of  the  result:  B'. 


J 


Ill 


OPEEATOR 
NAME 


pass  2 
MS TACK 
BEFORE 


TABLE  5 
(CONTINUED) 

pass  2 

MS TACK 

AFTER 


DESCRIPTION 


< 
< 
> 

UTRANSF 
CTRANSF 


,C,B,A| 

.c,b,a| 
,c,b,a| 
,c,b,a| 
,c,b,a| 
b,a| 

c,b,a| 


..C,B 
. .  C  jB 
. .  C ^B 
«  •  C  ^  B 
.  .  C ^B 


..C 


as  above  but  for  less  than. 

as  above  but  for  less  than  or  equal  to. 

as  above  but  for  greater  than  or  equal  to. 

as  above  but  for  equal  to. 

as  above  but  for  not  equal  to. 

Emit  an  unconditional  transfer  to  the 
address  pointed  to  by  A. 

Emit  a  conditional  transfer  on  false  to 
the  address  pointed  to  by  A  on  the  condi- 
tion whose  address  is  pointed  to  by  B. 


SE  TADDRUTRAHSF   . . . C  ^ , A | 

SETADDRCTRANSF   ...C,B,a| 
STOREADDR       ...B,a| 


. C|     Set  the  address  field  of  the  unconditional 
transfer  which  is  at  the  address  pointed 
to  by  A  with  the  address  pointed  to  by  B. 

C|     As  above  but  conditional  transfer. 

b|     Store  in  the  location  pointed  to  by  A  the 
address  at  which  the  next  instruction  will 
be  placed. 


ENDOFIT 


^A 


A 


Emit  a  HALT  instruction. 
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6.2.2  Planning  the  Structure  of  a  Pass 

This  section  describes  the  structure  of  pass  1  semantics  for 
DEMALGOL  I.  There  are  four  main  data  structures  (besides,  of  course,  BIGTAB 
and  MSTACK).  They  are  the  tables  IDTAE,  LKLIST  and  BLOCKSTACK  and  the  stack 
IFSTACK.  The  structure  of  the  tables  is  detailed  in  Figure  15  and  the  stack 
is  displayed  in  Figure  l6.  The  SEM  field  of  BIGTAB  and  MSTACK  was  redefined 
using  ^DDCOL  declarations  as  illustrated  in  Figure  17 . 

Appendix  D  presents  a  listing  of  the  pass  1  semajitic  description  of 
DEMALGOL  I  in  ISL.   References  will  be  made  to  the  number  of  each  card,  on  the 
right  hand  side  of  the  page.   Lines  6  through  2U  contain  the  declarations  of 
the  tables  and  stack  and  the  $ADDCOL  declaration.   These  declarations  should 
not  present  any  difficulty  since  they  were  used  as  examples  in  Chapter  k. 
Seven  integers  are  used  in  the  program  besides  MAXPTABTAB  which  has  already 
been  discussed.   TEMPI,  TEMP2  and  TEMP3  are  used  for  temporary  storage;  I  is 
used  as  index  of  FOR  loops;  STORETYPE  stores  the  last  type  found,  i.e.,  integer, 
boolean  or  label.   These  types  were  assigned  the  numbers  3>  2  and  1  respectively 
and  the  DEFINE  in  line  5  allows  the  use  of  the  mnemonic  identifiers  INT,  BOOL 
and  LAB  instead  of  the  numbers  above.   CULEVEL  stores  the  current  level  of  the 
program;  i.e.,  the  depth  of  block  nesting.   It  is  incremented  each  time  a 
#BEGIN  is  foimd  and  decremented  each  tijne  an  #END  is  found.   Finally,  PTABTAB 
is  a  pointer  to  the  next  available  work  area  location  in  pass  2.   Note  the 
#UPPERN  declaration  in  line  25  which  shows  that  this  was  just  a  syntax  check 
run.   The  declarations  are  completed  by  a  FORMAT  declaration  and  a  procedure 
declaration:   ERR0R(ERR0RNUMBER,PTT0BIGTAB) .   This  procedure  is  called  each 
time  the  semantics  identifies  a  semantic  error.   It  prints  an  error  message  on 
the  file  LINE  (i.e.,  the  same  file  the  parser  will  be  using  to  output  a  listing) 
containing  an  error  number  and  the  identifier  which  caused  that  error.   The 
meaning  of  each  error  number  (l  through  5)  is  listed  as  a  comment  in  cards  31-39' 
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It  is  interestinc  to  note  how  the  procedure  picks  the  identifier  out  of 
BIGTAP:   The  parameter  is  a  pointer  to  the  heading  of  the  entry  of  the 
identifier  in  BIGTAB.   The  $OPD  in  line  kO   picks  the  number  i  in  column  WORDS 
of  BIGTAB  and  this  niomlDer  is  used  as  the  upper  limit  of  a  FOR  loop  which  picks 
the  i+1  words  following  the  heading  and  prints  the  rightmost  six  characters  of 
each.   Notice  also  that  ERROR  increments  the  global  variable  MMERRS  as  de- 
scribed in  Section  2. 3-2. 3- 

To  complete  the  description  of  the  structure  of  pass  1,  it  is  neces- 
sary to  describe  how  the  tables  and  stacks  are  used.   The  main  table  is  IDTAB 
which  keeps  one  entry   (i.e.,  one  row)  per  declaration  of  each  identifier. 
The  field  PTTOBIGTAB  of  each  entry  in  IDTAB  points  to  the  heading  of  the  entry 
of  the  identifier  in  BIGTAB*  All  entries  in  IDTAB  which  correspond  to  the  same 
identifier  are  linked  together  by  back  pointers  which  are  kept  in  the  column 
BACKPT.   If  an  identifier  has  BACKPT  =  0,  this  means  that  it  was  the  first 
entry  of  that  identifier  in  IDTAB.   Notice  that  the  same  identifier  can  be 
entered  several  times  in  IDTAB  because  the  same  identifier  can  be  repeatedly 
declared  in  different  blocks. 

The  field  PTTOIDTAB  of  BIGTAB  contains  a  pointer  to  the  latest  entry 
of  the  identifier  in  IDTAB  which  is  still  useful,  i.e.,  PTTOIDTAB  will  point 
to  the  valid  declaration  of  an  identifier  at  a  certain  level  while  the  chain 
of  BACKPT 's  links  entries  of  the  same  identifier  in  outer  blocks  (i.e.,  lower 

levels).   The  remaining  fields  of  IDTAB  are  used  as  follows:   PTTOAETAB  keeps  a 

I 

I  pointer  to  the  work  area  location  of  pass  2  that  will  contain  the  absolute  ad- 
dress associated  with  that  entry.   LEVEL  stores  the  value  of  CULEVEL  at  the 

i moment  that  entry  was  made.   TYPE  designates  which  type  the  entry  correspond 

jto:   BOOL,  INT  or  LAB.   The  three  remaining  fields  are  used  only  for  labels: 
USED  is  a  bit  that  is  set  when  a  declared  label  appears  in  a  GOTO  statement; 

1  FOUND  is  set  when  a  declared  label  is  found  lateling  a  statement  aiid  PTTOLKLIST 
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points  to  the  latest  of  the  entries  in  a  linked  list  of  forward  references  to 
a  label.   This  linked  list  is  kept  in  the  table  LKLIST.   Column  LIM  of  this 
table  points  to  the  previous  entry  in  the  linked  list.   LIM  =  0  means  the 
initial  (i.e.,  the  oldest)  entry  in  the  list.   The  other  field  of  LINKLIST  : 
PTTOABTAB  contains  a  pointer  to  the  work  area  location  in  pass  2  which  contains  " 
the  address  of  the  transfer  instruction  whose  destination  address  must  be  set 
when  the  forward  label  is  finally  found.   Table  BLOCKSTACK  is  used  as  a  stack 
to  recover  pass  2  work  area  space  (field  PTABTAB)  and  linked  list  space  (field  1 
PTLKLIST) .   When  a  block  is  entered,  the  values  of  PTABTAB  and  PTLKLIST  are     | 
pushed  into  BLOCKSTACK.  When  the  block  is  left,  BLOCKSTACK  is  popped  into 
these  two  locations,  thus  recovering  the  locations  that  are  no  longer  needed 
since  the  block  ended.   The  stack  IFSTACK  allows  the  implementation  of  nested 
IF  statements.   Obviously,  each  IF  statement  in  DEMALGOL  needs  two  transfer 
instructions:   one  conditional  and  one  unconditional  and  both  are  to  forward 
points.   Thus,  the  address  of  these  transfers  must  be  stored  so  that  the  ad- 
dress field  may  be  fixed  when  the  desired  point  is  foimd.   IFSTACK  keeps,       I 
before  the  ELSE  is  found,  a  pointer  to  the  address  of  the  conditional  trans- 
fer and,  after  the  ELSE  appeared  but  before  the  end  of  the  IF  statement  is 
found,  a  pointer  to  the  address  of  the  unconditional  transfer.   This  completes 
the  description  of  the  basic  structure  of  pass  1.  Further  details  are  pre- 
sented in  the  analysis  of  the  semantic  actions. 

6.2.3  Assigning  Semantic  Calls  to  the  Syntax  and  Writing  the  Semantic  Actions 

The  assignment  of  semantic  calls  is  analyzed  in  detail  for  the  BNF 
syntax  of  DEMALGOL  (Appendix  B).  As  each  semantic  call  is  discussed,  the 
corresponding  semantic  action  is  described.   This  implementation  of  DEMALGOL 
pass  1  uses  only  21  semantic  actions  directly  called  and  one  auxiliary  action 
(action  "22")  which  is  called  from  actions  "7"  and  "18"  by  means  of  the  $EXEC 
construct. 
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The  first  production  (l -line  l)  defines  a  program  and  action  "l" 
has  been  assigned  to  it  simply  to  emit  the  IL  operator  EWDOFIT  (D-line  50). 
ENDOFIT  generates  code  for  a  HALT  instruction,  or  a  call  to  SYSTEM  in  more 
elaborate  installations. 

Semantic  action  "2"  is  called  when  an  #ENI)  is  found  (B-line  2). 
This  semantic  routine  must  "erase"  all  the  declarations  which  were  found  in 
that  block.   This  is  done  as  follows  (D-lines  51-62) :   starting  with  the  last 
occupied  position  of  IDTAB  all  declarations  with  LEVEL  =  CULEVEL  are  erased  by 
setting  PTTOIDTAB  in  BIGTAB  to  the  previous  declaration  (which  now  is  valid 
again)  of  the  same  identifier.   This  previous  declaration  is  located  using 
BACKPT . 

As  integer  or  boolean  declarations  are  erased,  the  appropriate 
FORGETSPACE  operators  are  emitted  to  recover  the  memory  locations  which  were 
assigned  to  these  variables.   As  label  declarations  are  erased,  a  check  is 
performed  to  find  out  if  a  forward  reference  was  never  satisfied;  i.e.,  if  a 
label  was  used  in  a  GOTO  statement  but  never  found.   This  situation  defines 
semantic  error  f(^2.   The  "erasure"  proceeds  until  an  entry  is  found  with 
LEVEL  <  CULEVEL  indicating  that  all  the  declaration  part  of  the  block  that 
ended  was  taken  care  of.   Then  the  value  of  MAXPTABTAB  is  updated  to  the  maxi- 

'  mum  between  the  previous  MAKPTABTAB  and  the  value  reached  in  this  block. 
1 

;  BLOCKSTACK  is  popped  (D-line  6k)    as  already  described  and  CULEVEL  is  decre- 
mented. 

When  a  #BEGIN  is  found,  semantic  action  "3"  is  called.   This  action 

i 
simply  increments  CULEVEL  and  pushes  BLOCKSTACK  (D-lines  66-67).   Actions  "U", 

'5"  and  "6"  are  called  when  each  type  is  found  (B-line  8)  and  sjjnply  set 

STORETYPE  to  the  appropriate  value.  Action  "7",  called  when  each  identifier 

is  found  in  a  <type  list>  (B-line  9)  performs  the  entry  in  IDTAB.   PTTOIDTAB 

of  BIGTAB  is  adjusted  to  point  to  this  latest  entry  and  BACKPT  is  set.   Note, 
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however,  that  if  PTTOBIGTAB  points  to  an  entry  with  LEVEL  =  CULEVEL,  this 
means  that  the  identifier  has  already  been  declared  before  in  the  current 
block.   Thus,  semantic  error  #1  is  detected.  Note  also  that,  if  the  declara- 
tion was  for  an  integer  or  a  boolean,  the  operator  GETSPACE  is  emitted  preceded 
by  the  appropriate  parameters.   One  location  of  pass  2  work  area  (PTABTAB)  is 
reserved  for  each  entry  in  IDTAB.   Auxiliary  action  "22"  performs  the  actual 
entry  in  IDTAB. 

Action  "8"  is  called  when  a  label  is  found  (B-line  l6)  and  Action 
"9"  when  a  label  is  used  (B-line  17) •   When  the  label  is  found,  a  check  is 
performed  to  make  sure  not  only  that  it  was  declared  (semantic  error  ^k)   but 
also  that  the  declaration  occurred  in  the  innermost  block  (semantic  error  #3) • 
Action  "8"  also  emits  code  to  fill  the  pass  2  work  area  location  associated 
with  the  label  with  the  actual  absolute  address  to  which  the  label  corresponds 
(D-lines  85-86).   Finally  the  linked  list  of  forward  references,  if  any,  is 
eliminated  with  the  emission  of  one  operator  SETADDRUTRANSF  (preceded  by  the 
appropriate  parameters)  per  forward  reference  (D-lines  90-92)'   Action  "9" 
must  output  a  UTRANSF  operator  and,  if  the  label  has  not  been  found  yet,  enter 
a  pointer  to  the  address  of  the  unconditional  transfer  in  the  linked  list 
associated  with  that  label. 

Action  "10"  is  the  only  semantic  test  needed  in  this  program.   Its 
reason  and  effect  have  already  been  discussed  since  this  case  was  used  as  an 
example  in  Section  2. 3-2. 2.   The  semantic  test  is  needed  twice  in  this  language: 
B-line  20  and  B-line  U^i. 

Actions  "11"  and  "12"  emit  STORE  operators  to  implement  the  assignment 

states:   arithmetic  and  boolean.   Note  that  Action  "12"  also  checks  for  the 

previous  declaration  of  the  left  hand  side  identifier  as  a  boolean  (D-line  11?) 

and  this  constitutes  the  last  semantic  error:  #5-  Action  "ll"  does  not  have  to 

perform  this  kind  of  check  because  it  has  already  been  performed  by  "10"  in  the 
semantic  test. 
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Actions  "13",  "iH"  and  "15"  ijnpleinent  IF  statements.   '13  is  called 
after  the  boolean  expression  is  found  and  basically  emits  a  CTRANSF.   "lU"  is 
called  when  the  THEN  part  is  complete.   It  fixes  the  conditional  transfer  and 
emits  UTRAUSF  which  is  fixed  by  "15",  when  the  ELSE  part  is  complete.   The  use 
of  IFSTACK  to  make  possible  the  implementation  of  nested  IF's  has  already  been 
discussed. 

Action  "l6"  is  particularly  interesting:   It  is  the  only  use  of  a 
dynamic  operator  in  this  program.   It  is  used  in  five  different  calls  (B-lines 
38,  ^2,  48,  50  and  5^)  and  is  solely  responsible   for  the  emission  of  the 
operators:  +,  -,  X,  /,  AND,  OR,  >,  >,  <,  <,  =,  and  j=.   Obviously,  this  language 
will  use  the  option  SPSTAB  TEEIMINALS  in  pass  1  to  create  the  link  between  the 
terminals  code  numbers  and  IL  operators  code  numbers.   Note  that  postfix  code 
results  automatically. 

Actions  "17"  and  "19"  emit  IL  operands  corresponding  to  identifiers 
which  have  been  parsed  as  arithmetic  primaries  and  boolean  primaries  respec- 
tively.  As  in  "11"  and  "12",  "19"  checks  for  error  #5  while  "l?"  does  not 
since  "lO",  called  just  before  "17,"  has  already  done  the  checking. 

Action  "18"  takes  care  of  numbers.   Numbers  are  treated  as  self- 
declarations  and  an  entry  in  IDTAB  is  made  for  each  number  the  first  time  it 
'    appears  in  a  block.   When  the  bit  NUMBEROK  of  BIGTAB  is  zero,  it  means  that  the 
number  has  not  yet  appeared  in  this  block  and  thus  it  must  be  created.   The 

initialization  parameter  of  the  GETSPACE  operator  is  used  to  give  the  location 
f 

'  reserved  for  the  number  the  proper  initial  value. 
! 

Note  that  ^TRUE  and  #FALSE  are  not  considered  self-declarations  as 

1  are  the  nianbers.   In  fact,  they  are  treated  (in  Actions   "20"  and  "21")  with 

I 

j    references  to  fixed  pass   2  work  areas:      locations  0  and  1  which,    in  the   initial- 

I    ization  action  "O",   were   assigned  to  point   to  the   absolute   address   of  the   con- 

I    stants  #FALSE  and  #TRUE  respectively.      Thus,    instead  of  being   created  once   for 

i 
I 

I 
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each  block  in  which  they  appear,  #TRU1'^  and  #FALSE  are  created  only  once,  at  the 
initialization,  as  if  they  were  the  two  first  declarations  in  the  outermost  block. 

This  semantic  description  of  DEMALGOL  I  has  actually  been  used  to 
create  a  compiler  and  to  parse  sample  programs.  The  listings  corresponding  to 
these  tests  can  be  found  in  [h] . 

The  assignment  of  semantic  action  calls  to  the  English-like  version 
of  the  syntax  (Appendix  C)  is  a  little  more  complex.   The  difficulty,  however, 
is  simply  solved  if  one  compares  Appendices  B  and  C  to  determine  where  a 
semantic  call  should  be  placed  in  the  English-like  form  to  obtain  the  same 
effect  as  in  the  BNF  form.   Very  often  brackets  must  be  used  when  associating 
semantics  to  the  English-like  constructs  of  TWINKLE  (See,  for  example, 
C-line  10). 
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APPEOTDIX  A 
FORMAL   SYFTAX   OF  ISL 
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This  appendix  contains  the  formal  definition  of  ISL.   This  definition 
is  presented  through  BNF  productions.   There  is,  however,  one  major  explanation: 
Since  ISL  contains  BeA,  it  would  be  rather  extensive  to  present  all  of  it  here. 
Therefore,  only  the  non-ALGOL  ISL  constructs  are  defined  here.   The  definitions 
of  the  BeA  constructs  given  in  [l]  are  in  effect  and  they  are  referred  to  by 
the  following  notation  "BeA  n-m:",  where  n  and  m  are  integers.  Whenever  this 
notation  appears  inside  non-terminal  brackets  before  the  non-terminal  name,  it 
indicates  that  the  definition  of  the  non-terminal  is  given  in  [l],  page  n-m. 
In  order  to  use  [l]  as  a  complement  of  the  definition  of  ISL,  however,  certain 
definitions  in  this  BeA  manual  should  be  added  to  in  order  to  include  ISL 
constructs.   This  is  what  is  done  in  productions  1-7  below.   These  are  the  only 
productions  in  which  a  BeA  reference  appears  in  the  left-hand  side;  moreover, 
the  same  reference  appears  in  the  right-hand  side.   The  meaning  of  these  pro- 
ductions is:   the  referred  BeA  non-terminal  should  be  modified  to  include, 
besides  its  original  definition,  the  indicated  ISL  constructs.   Finally,  many 
of  the  non-terminals  which  appear  in  the  remaining  of  the  syntax  are  qualified 
by  footnotes  indicating  restrictions  which  cannot  be  conveniently  expressed  in 
BNF. 
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1.  <BeA  9-1    :    d.eclaration>    :  :=  <BeA  9-1    :   declaration>    |    <ISL  declaratiorO 

2.  <BeA  ^4-1)4    :    label>    :  :=  <BeA  ^4-14    :    label>    |    <action  label> 

3.  <BeA  6-2    :   unlabeled  basic  statement>    :  :  = 

<BeA  6-2    :   unlabeled  basic  statement>    |   <ISL   simple   statement> 

k.     <BeA  5-1    :   unlabeled  ccmpound  statement>    ::= 

<BeA  5-1    '•   unlabeled  compound  statement>   |    <ISL   compound  statement> 

5-     <BeA  3-3    '■   partial  word  designat  or>     :  :  = 

<BeA  3-3    '  partial  word  designator>   |    <ISL  operand> 

6.  <BeA  3-7    :    function  designator>    : := 

<BeA  3-7    :    function  designator>    |    <search  operand> 

7.  <BeA  3-1    :    simple  variable>    : :=  <BeA  3-1    :    simple  variable>    | 

<pointer  operand> 

8.  <prograiii>    :  :=  $BEGIN  <declaration  part>   ;  <action  label>    : 

<exe  cut  able  part>  $EKD   |    $BEGIN  <action  label>    : 
<exe  cut  able  part>  $EWD 

9-     <declaration  part>    : :=  <list   of  declarations> 

10.  <list   of  declaration^    :  :=  <BeA  9-1    '   declaration>   | 

<list   of  declarations>   ;  <BeA  9-1    '•   declaration> 

11.  <action  label>    : :=  $ACTION  (<generalized  identifier>   ) 

12.  <generalized  identifier>    : :=  <BeA  2-1    :   letter>   |   <BeA  2-1    :   digit>    | 

<generalized  identifier>  <BeA  2-1    :   letter>   | 
<generalized  identifier>  <BeA  2-1    :   digit> 
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13-     <exe cut able  part>    : :=  <BeA  1-4    :    empty>   | 

<exe  cut  able  part>   ;  <BeA  6-1    :    statemen-t> 

l4.     <ISL  declaration>    :  :=  <ta'ble  declaration>   |   <stack  declaration>   [ 

<cell  declaration>   |   <add  column  declaration>   | 
<nuinber  of  actions  declaration>   |   <in  declaration>   | 
<  ISL  define  declaration>    | 
<forward  action  declaratiori>   | 
<end  of  declarations  declaratiori> 

15'     <ISL   simple   statement>    : :=  <increment   statement>    | 

<decrement   statement>   | 
<execute   statement> 

16.  <ISL   compound  statement>    :  :=  <push  statement>    |   <pop  statement> 

<enter  statement>    |   <code   statement> 

17.  <table  declaration>    : :=  $TABLE  (<list   of  table   specifications>) 

18.  <list   of  table   specification^    :  :=  <table   specification  >   | 

<list   of  table   specificationa>   ; 
<table  specificatiori> 

19.  <table   specification>    :  :=  <table   identifier>   ,  <number  of  ro-ws>   , 

<list   of  column  specificationa> 

20.  <list   of  column  specificationa>    : :=  <column  specification>    | 

<list   of  column  specification^   , 
<col"uimn  specification> 
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21.  <coliimn  specif icatiorO  :  :=  <coliimn  identifier>  =  <left  bit  of  field>  : 

<  bits  in  field> 

22.  <n\jmber  of  rows>  :  :=  <BeA  2-6  :  unsigned  integer> 

23.  <left  bit  of  field>  :  :=  <BeA  2-6  :  iinsigned  integer> 
2k.     <bits  in  field>  : :=  <BeA  2-6  :  unsigned  integer> 

25.  <table  identifier>  : :=  <BeA  2-5  :  identifier  > 

26.  <column  identifier>  : :=  <BeA  2-5  :  identifier~> 

27.  <stack  declaratiori>  :  :=  $STACK  (<list  of  stack  specification^) 

28.  <list  of  stack  specif ications>  : :=  <stack  specification>  | 

<list  of  stack  specif icationa>  ; 
<stack  specif ication> 

29.  <stack  specification>  :  :=  <stack  identifier>  ,  <number  of  row^ 

30.  <stack  identifier>  : :=  <BeA  2-5  :  identifier  > 

31.  <cell  declaration>  : :=  $CELL  (<list  of  cell  specifications>) 

32.  <list  of  cell  specificationa>  : :=  <cell  specification>  | 

<list  of  cell  specifications>  ; 
<cell  specif icatiori> 

33-  <cell  specificatiori>  : :=  <cell  identifier>  ,   <list  of  column  specif icationa> 

3^.  <cell  identifier>  :  :=  <BeA  2-5  :  identifiers* 

35-  <add  column  declaration>  : :=  $ADDCOL  (<list  of  add  column  specif ications>) 
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36.  <list  of  add  column  specification^  :  :=  <add  column  specificatiori>  | 

<list  of  add  coli:imn  specification^ 
<add  colimn  specificatiori> 

37'  <add  colimm  specification>  :  :=  <table  identifier  >  , 

<list  of  column  specifications>  j 

5 
<cell  identifier  >  , 

<list  of  column  specifications> 

38.  <number  of  actions  declaratiori>  :  :=  $UPPEIIN  (<BeA  2-6  :  unsigned  integer>) 

39"  <in  declaration>  ::=  $IN  (<list  of  declarations  >) 

kO.     <ISL  define  declaration>  : :=  $DEFINE  (<ISL  definition  list>) 

4l.  <ISL  definition  list>  : :=  <ISL  definition  part>  | 

<ISL  definition  list>  ,   <ISL  definition  par-t> 

k2.     <ISL  definition  part>  : :=  <ISL  defined  identifier>  = 

<BeA  9-7  :  definition>  # 

k3.     <ISL  defined  identifier>  :  :=  <BeA  2-5  :  identifier^ 

hk.     <forward  action  declaration>  : :=  $FORWARD  (<list  of  action  identifiers>) 

45.  <list  of  action  identifiers>  : :=  <generalized  identifier  >  | 

<list  of  action  identifier^  , 

7 
<generalized  identifier  > 

o 
1+6.  <end  of  declarations  declaratiori>  :  :=  $EKDEC 

^7.  <ISL  operand>  :  :=  <table  operand>  |  <stack  operand>  |  <cell  operand> 
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hQ.     <table  operand>  : :=  $OPD  (<table  identifier  >)  ,  <row  information>  , 

<col'uinn  infonnation>) 

Q 

U9.  <stack  operand>  : :=  $OPD  (<stack  identifier  >  ,   <row  information>) 

50.  <cell  operand>  : :=  $OPD  (<cell  identifier  >  ,  <column  information>) 

51.  <row  information>  :  :=  <BeA  ^4-1  :  arithmetic  expression>   |  $NOW  [  $NEXT 

$TOP  I  $TOP  <BeA  k-2    :  adding  operator> 

<BeA  ^-1  :  arithmetic  expression> 

52.  <coliimn  information>  :  :=  <column  identifier  >  |  $ALL   | 

12 

$ALL  <BeA  ^-1    :    arithmetic  expression> 

53*     <search  operand>    :  :=  <stack  search  operand>   |   <ta'ble   search  operaJid> 

5^.     <stack  search  operand>    ::=  $SEARCH  (<stack  identifier">   , 

<BeA  k-1    :    arithmetic  expression>) 

I4. 
55-     <table   search  operand>    :  :=  $SEARCH  (<ta'ble   identifier  >   , 

<col"umn  infonnation>   , 

<BeA  4-1    :    arithmetic  expression>) 

56.  <pointer  operand>    :  :=  $POIM'ER   (<table   identifier  >)    | 

^POINTER   (<stack  identifier^) 

57.  <increment   statement>    : :=  $INCR   (<leftmost  left  part>) 

58.  <leftinost  left  part>    :  :=  <BeA  3-3    :  partial  word  designator>   | 

<BeA  3-1    :   varia'ble> 

59-     <decrement   statement>    : :=  $DECR   (<leftmost  left  part>) 
60.     <execute   statement>    :  :=  $EXEC   (<generalized  identifier"S>) 
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6l.      <push   statement>   ::=  <stack  push   statement>   |    <table  push  statement> 

62.  <stack  push  statement>    ::=  $PUSH  (<stack  identified    : 

<Btk  k-1   :   arithmetic  expressioii>) 

h 

63.  <table  push  statement>  :  :=  $PUSH  (<talDle  identifier  >  ,  <entry  list>) 

64.  <entry  list>  ::=  <entry  eleinent>  |  <entry  list>  ,  <entry  element> 

65.  <entry  element>  :  :=  <coluinn  information>  :  <BeA  4-1  :  arithmetic  expression> 

66.  <pop  statement>  :  :=  <stack  pop  statement>  |  <ta'ble  pop  statement> 

67.  <stack  pop  statement>  :  :=  $POP  (<stack  identifier^  ; 

<leftmost  left  part>)  | 
$POP  (<stack  identifier">) 

68.  <ta'ble  pop  statement>  :  :=  $POP  (<table  identifier  >  ,   <pop  entry  list>)  [ 

$POP  (<table  identifier  >) 

69*  <pop  entry  list>  ;  :=  <pop  entry  element> 

<pop  entry  list>  ,   <pop  entry  element> 

70.  <pop  entry  el ement>  : :=  <  column  information>  :  <leftmost  left  part> 

71.  <enter  statement>  : :=  <cell  enter  statement>  |  <table  enter  statement> 

72.  <cell  enter  statement>  : :=  $ENTER  (<cell  identifier  >  ,  <entry  list>) 

k 

73.  <table  enter  statement>  : :=  $ENTER  (<table  identifier  >  , 

<row  information>  ,   entry  list>) 

74.  <code  statement>  : :=  $CODE  (<list  of  operators  and  operand£>) 
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75-  <list  of  operators  and.  operands>  :  :=  <operator>  |  <operand>  | 

<list  of  operators  and  operands>  , 

<operand>  [ 

<list   of  operators   and  operandi  , 

<operator> 

76.     <operand>    :  :=  <BeA  h-l    :    arithmetic  expression> 

77*     <operator>    :  :=  <dynainic  operaotr>   [   <static  operator> 

78.  <dynamic  operator>    :  :=  jl<Bek  h-\    '    arithmetic  expressiori> 

79.  <static  operator>    :  :=  *"<BeA  1-U    :    character>"    | 

*  <generalized  identifier> 

80.  <definition  call>    :  :=  $DF  <ISL  defined  identifier"'"^"'" 
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FOOTNOTES : 


1.  The  generalized  identifier  must  have  appeared  before  in  a  <forward  action 
declaration>  or  in  a  semantic  action  call  or  semantic  test  in  the  syntax. 
Moreover,  this  construct  can  label  only  statements  in  the  outermost  block. 

2.  The  identifier  must  not  have  been  used  before  in  another  declaration  in  the 
same  block. 

3'  The  identifier  must  not  have  been  used  before  in  the  same  <table  specif i- 
cation>. 

k.      The  table  identifier  must  have  appeared  previously  in  a  <table  declaration> 
now  in  effect. 

5-   The  cell  identifier  must  have  appeared  previously  in  a  <cell  declaratiorO   J 
now  in  effect.  ■ 

6.   The  list  of  declarations  may  not  contain  an  <in  declaration>. 

7'   The  generalized  identifier  must  later  appear  in  an  <action  label>. 

8.  This  declaration,  when  present,  must  be  the  last  declaration  in  the  block. 

9.  The  stack  identifier  must  have  appeared  previously  in  a  <stack  declaration> 
now  in  effect. 

10.  The  column  identifier  must  have  appeared  previously  in  the  <table  declaratior 
or  <cell  declaration>  referred  to  by  the  construct. 

11.  This  type  of  column  information  myst  be  used  with  tables  or  cells  that  do 
not  use  more  than  one  word  per  row. 

12.  This  type  of  column  information  must  be  used  only  with  tables  or  cells  that 
use  more  than  one  word  per  row. 

13.  The  ISL  defined  identifier  must  have  appeared  previously  in  an  <ISL  define 
declaration>  now  in  effect.  Moreover,  there  must  be  no  space  between  the 
$DF  and  the  identifier. 

1^.  Definition  calls  may  appear  at  any  place  in  which  the  corresponding 
<definition>  might  appear. 


129 


APPEMDIX  B 
SYTOAX   OF  DEMALGOL   I   IN  TWINKLE   -  BNF  FORM 
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<PRO(tRAH>  Mil  <BLOCK>  »S  1  )  1 

<ULOCK>  IIB  <HEAO>  <TAIL>  «CND  »S  2  i  .  '^ 

<HE:Aa>  lis  fbCGIN  »S  3  <0eCLARAT10N  PART>  <l  /  «BEaiN  •!  1  J  4 

<t)ECLARATlON  PAKT>  H»  ^DECLARATION  CART>  <8E^*«AT0R»  * 

<TYPE>  <TYPE  LI8T>  I  * 

<DECl.ARAl  ION  PaRT>  II»  <TYPE>  <TYPE  UIST>  I  ft 

<SEPARATUR>  |l»  HI  /  <COMMENT>  ^  ' 

<TYPE>  li«  HINTEQER  »S  4  /  «LABEL  »S  3  /  HBOOlEAN  *8  •  '  <* 

<TYPE  LlST>  !«■  <TYPE  LlST>  i#  «•!>  fS  ^  /  <•!>  f8  ?  I  * 

<TAIL,>  •«■  <TAIL>  <SEPARATOR>  <S1ATEmEnT>  /  «5TATEMlNT>  I  l« 

<STATEMENT>  |l«  <BLOCK>  /  U 

<G0  TO  STATEMENT>  /  ^^ 

<ASSIGNMtNT>  /  1  ■* 

<1F  PART>  <THEN  PART>  <ELSE  PART>  /  1* 

<  >  /  la 

<LABEL>  PS  S  t%    <STATEMENT>  I  ^^  ! 

<(iU  TO  $TATEHENT>  M*  <Q0  TO  SYMBOL>  <LABEL>  BS  9  I  W 

<G0  TO  SYMBOL>  M«  'GOTO  /  *Q0  *T0  /  iQO  I  1<>  ' 

<LA8tL>  «l»  <•!>  )  ** 

<ASSIGNMENT>  M«  <*I>  BT  10  <ASSIQN  ARRON^  20; 

<ARITHHETIC  EXPRE»SION>  BS  U  /  ^^ 

<*I>  <ASSIGN  ARRQM>  <BOOLEAN  EXPREISION»  Bl  12  I  22 

<ASSIGN  ARROtO  ll«  •••  /  #1  •■  I  2* 

<IF  PARr>  I  IB  #IF  <BOOLEAN  EXPREBSION>  BS  IJ  I  2« 

<THEN  PANT>  II*  BTHEN  <STATEMENT>  BS  U  i  2» 

<ELSe  PANT>  II"  BELSE  <STATEMENT>  BS  IS  J  2B 

<CQMMENT>  lla  BCOMMENT  <COMMENT  BOOY>  *l    I  11 

^COMMENT  BOOY>  Mb  <ANYTHlNa  BUT  SEMiCQLON>  /  2B 
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<COMMtNT  BODY>  <ANYTH1NQ  BUT  SEMIC0L0N>  I 
^YlHlNb  BUT  StMICULUN>  II*  <*I>  /  <*N>  /  <*S>  /  #BEOIN  /  tlHO    / 

»aO  /  'TO  /  'GOTO  /  fCOHMENT  / 
HINTEGLK  /  'BOOLEAN  /  'LABEL  /  »IK  / 
'THEN  /  'ELSE  /  'ANO  /  'OR  / 
'TKOE  /  'FALSE  / 
'«/'!/"/'»/'.; 
aiHMETIC  EXPKESSiON>  ll»  <TEHM>  / 

<ANiTHMETlC  EXPRESSION> 

<Ay01Nii  OPERATOH>  <TERM>  VS  16  I 
)DiN(j  UPERATOH>  |I«  '♦/'-; 
RM>  lie  <ARnHMETIC  PKIMARY>  / 

<TERM>  <MULTlKLYlN(i  UPERATOR> 
<AKITHMETIC  PRIMARY>  9S    16  ; 
JLUPLYING  0PERATUR>  II»  $k    /    $/    t 

(IIHMETIC  PRIMARY>  ll«  <*!>  #T  10  fS  17    /    <*N>  dS  Ifl  / 

'(  <AR1THMEHC  EXPRESSION>  ')  ; 
)OLtAN  EXPKESSiON>  li«  <800LEAN  TEKM>  / 

KBOOLEAN  EXPRESSION>  'OH 
<eUOLtAN  TERM>  9S  16  J 
lOtEAN  TERM>  H«  <BUOLtAN  PRIMARY>  / 

<BOOLEAN  TERM>  'AND  <BOOLEAN  PRIMARY>  PS  16  J 
JGlEAN  PRIMARY>  |I»  <*l>  »S    19  /  'TRut  «IS  20  /  'FALSE  fS  21  / 
'(  <BOOLEAN  EXPRESSION>  ')  / 

<ARITHHETIC  EXPRESSION>  <RELATIONAL  OPERATON> 
<ARITHMETIC  EXPKESSION>  9S  16  J 
LATIONAL  OPEHATOK>  ii>  '•/'#/'</  'S  /»>/  '2  I 


2'^ 

Jl 
J^ 

ii 

J« 
J5 
ib 
i( 
i0 
iV 
4U 
Ml 
4<! 
4J 
44 
4S 
46 
4^ 
40 

4y 

SI 

3^ 
Si 
S4 
5> 
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APPENDIX   C 
SYNTAX   OF  DMALGOL   I   IN  TWINKLE   -  ENGLISH -LIKE  FORM 
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A  <KHIJGHAH>  IS  UtriNEO  TU  til    A  <BLUCK>  CS  1  i 

A  <blliCH>  CUNSIS-TS  or  »BtGIN  PSi    FULLONtO  BY  POSSIBLY  ONE 
[Lli.1  nF  <0tCLAKAT10N>S  SEPARATED  bT  <CUMMENT>S  roLtaWEO  BY  $1     ] 
rui  LOWED  BY  A  LIST  OF  <STATEMENT>S  iEPAHATtU  BY  <COMMENT>S 
Rnl  LOhEu  BY  #ENo  ?Si!  ; 

4  <UECL*RATION>  CONSISTS  OF  6 

»lNTt(.E»  *SH    /    »BOULEAN  ?S5  /  #LABEL  »56  ]  V 

FuLLUrtEO  BY  A  STRING  Of  l<*l>  PS^  i     SEPARATED  BY  »t     I  lU 

U 
A  <bTflTEMEMT>  IS  DEFINED  TO  BE  C  <LABEL>  ?SS  li  ]*  FOLLOWED  BY  U 

r  I  IGO  »i|0  OR  *G0  OR  >GUTO  I  FOLLUnED  BY  A  <LABEL>  (^S?  OR  U 

<•!>  (l»nO  C«|  »•  OH  ««•  J  <AHITHMETIC  EXPRESSION>  #SU  OR  I  <• 

<-!>  f  *i  !•  OR  »♦•  ]  <B0OlEAN  ExPRESSION>  PS12  OR  15 

'If    <BO0LEAN  EXPRESSION*  9S13  «ThEN  <STATEMENT>  9S14  fELSE  <STATEHENT>  10 

9i\b    OK  EMPTY  )  i  W 

10 
«  -COHMtNT*  CONSISTS  Of  tt    UR  fCOMMENT  fOLLOHED  BY  A  POSSIBLY  IV 

ffifTY  LiST  OF  <ANYTHIN>i  BUT  SEMlCOLON>S  FOLLOWED  BY  *f    t  H) 

21 
A  <LABEt>  IS  DEFINED  TU  HE  AN  <*I>  (PROVIDCO  IT  HAS  APPEARED  22 

IN  A  DECLARATION  BEGINNING  WITH  *LABEL}>  '<ii 

H    <ARITHMET1C  EXPRESSION*  CONSISTS  OF  A  <TERM>  FOLLOWED  BY  A  PQSSIHLY  29 

EMPTY  LIST  OF  U  **    OR  »-  J  FOLLOWED  BY  A  <TERM>  »SU  ]  J  26 

if 
k    <TEHM»  CONSISTS  OF  AN  <ARITHMETIC  PRIMARY*  FOLLOWED  BY  A  POSSIBLY  2tt 
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tMPTf  LIST  Ur  tl  «>«  OR  »/  )  FOLLOWLU  BY  AN  <ARITHMETIC  PRIMART>  PSlftJI 

AN  vAHllHMEllC  KRIMARY>  CONSISTS  U^  l(  <ARITHMETK  tXPRE.SSlUN>  #)  OH 
«N  <"1>?T10  ?Sir  OH  A  <*N>  »S16  ) 

A  <tiOOLlAN  t.xPRtSSION>  CONSISTS  UF  A  <BUOLtAN  TERM>  FOLLOWtO  BY  A 

POSSIBLY  tMPTY 

LIST  OF  C  *UR  FULLUWEO  BY  A  <800LEAN  TEKM>  *S16  ]J 

A  <15UULLAN  TERM>  IS  OEUNED  TO  BE  A  <BOOLEAN  PRIMARY>  FOILUWEU  BY  A 
POSSiOLY  EMPTY  LISf  OF  t  fAND  <BO0CLAN  PRIMARY>  9S\6    J  J 

•^  <HOUI.EAN  PRIMARY>  CONSISTS  OF  #{  ^BOOLEAN  EXPrESSIUN>  «)  OR 

AN  <.AKnMMETIC  EXPHESSION>  fOLLOWEU  BY  t  #•/##/*>/»</»$  '  »*i 

FOt.LOWFU  bY  AN  <ARITHMETiC  tXPRESSIUN>  UR  AN  <*I>  »S19  OR 

*TP'J£  ^S2C  UR  »MLSt  es21  I 

AN  <ANY1H1N*>  BUT  StMICULUN>  CONSISTS  OF  <*I>  /  <*N>  /  <*S>  /  »BtGlN  / 
»EnU  /  »G0  /  #T0  /  »  GOTO  /  fCOMMENT  /  »InTEGER  /  »BOOUEAN  /  »I.ABfcL  / 
«IF  /  «fMtN  /  »tLSt  /  »ANO  /  «0R  /  »TRUt  /»FA|.SE  /*»    /  #1  /»»/»•  ^ 


j^ 

j:> 

it 
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iO 

jv 

4U 
41 
42 
4i 
44 
43 
46 
4^ 
40 
4V 
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APPENDIX  D 
SEMANTICS  OF  DEMALGOL  I  IN  ISL  -  PASS  1 
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»l  SEW  lOO^lOU  NtHSeo  USEIL 

HEGIN 

TNTtntR  SIORElYPt#  CULtvEL*  PTAUTAB»  lEMHl*  TEMP2/  TEMP3  #1  J 
TiWLGLH  MAXPTAHTAB  ; 

OLFlNt  LAbsl*,  BUUL'^t'  INT>3*<  LABELUSEUBUTNOTFOUNOad*  t 
»TABLt(I0IAB»l02;i»PTT0BIGTAB»  It  lit 
BACKPT     ■lailO* 
PTTOABTAB  «^«I0  t 
LEVEL      ■3214  # 
TYf'E       ■3612  . 
UStO       >3Sll  * 
FOUND      ■3Vil  t 
LABFIELU  »3btH    » 
PTT0LKLiST"«yi8  t 
REST       «3ttilU  I 
LKLIST*2b6#PnOABTAB»  lid  t 
LINK      s  9ia  ; 
BLUCKSTACK*16«PTABTAB  ■  lie  « 

PTLKLIST*  9I«  )  ; 
»STACR(IFiTACR»32)  t 
SADDCUL(B1GTAH«PTT01UTAB*6|1U  * 
NUHBENOK  a:>il   ) 
MSTACK*PTTOIUTAB"ttJlO  # 
NOMBEKOK  mfW     )  I 
SUPPEKN(22)  J 

rOHMAT  tRHORMtSSAGE("»*«**  SEMANTIC  EKHO"  #"»n* 
"  *  lUENTiriEH  IS  I  *#8A6)  I 
PROCEDURE  ERR0R(ERR0RNUMBLR«PTT0HI6TAH)I 

VALUE  EHRQRNUMBERfPTTOBIGTABJ  INTEGER  ERRORNUMBER'^TTOBiaT ABI 


1 

2 
i 
4 
3 
6 
/ 
B 
V 

lu 
u 

12 
13 
14 

Id 

16 
\< 
10 
IV 
2U 
21 
22 
23 
2« 
29 
26 
21 
2« 
29 


J-DI 


Bir.iN 

l,UMMtNT  SEMANTIC  tRKURS  IN  ULMAL^OL  1  I 

1  •  ID  HAb  ALHLAOY  BEEN  UEtCARtD  IN  THIS  BLOCK, 

2  -  A  LABEL  UECLARLD  ANU  UbEO  iN  A  BLOCK  UlU  NOT  AKPtAK, 

i    '    LAbEL  MAS  NUT  UECLAHEU  IN  THE  INNERMOST  BLOCK  IN  WHICH 

IT  OCCURSt 
<t  -  ID  HAb  NOT  BEEN  DECLAKLO  AS  A  LABEL  OR  HAS  NOT  BtEN 

OECLAKEO  AT  ALL, 
i  -  ID  HAS  NOl  BEEN  DECLAKLO  AS  A  BOOLEAN  UK  HAS  NUT  BEEN 
OECLAKEO  AT  ALL.  ; 
lEHPJ*tOKD(blGTAB»PT!OBI(iTAB/WORUS)i 
'<KlTL(LlNE»EHR0HMtSSA6E»EKHUhNUMBER#F0R  1*0  STEP  1  UnTIL  TtMPJ 

00  SUPU(B1GTAB*HTT0BI^TAB4I«1«ALL}H 
ilNCR(NUMEHKS) 
END  Of  KROCEUUKE  EKKUR  ) 


BEGINNING    OK    THE    SEMANTIC    ACTIONS 


'»ACTIUN(    0)1    CULtVEL*0>    PT  IDTAB^PTLKLIST^H    PTABTAB*-?) 

»COUE(0<BUOL'0**GET SPACE M*BOOLM'*GETSPACE)    I 
i1»ACTI0N(     ni    »COUE(*tNUOFIT)J 
?»ACTI0N(    2)1    FOR    I»PTIDTAB-1    STEP    -l    WHILE    «OPD( lOT AB# I#LEVtL  )• 

CULfcVEl    DO 
BEGIN 
I  SOPO(8IGTA8»SOPU(IDTA8«I*PTTOBIGTAB}«PTTOIDTAB)«' 

SOPD(IUTAB«I*BACKPT}    I 
IF    SUPD(IOTAB'l«LABFIELD)aLABeLUSeDBUTNUTFOUNU 

THEN    ERR0RC2«>0P0(I0TAB«I«PTT0BIGTABn    I 
IF    TEMPUS0P0(1UTABM«TYPE}#LAB    THEN 
SC00E(S0PD(IUTAB#I*PTT0A6TAB}* 
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TEMPl#*^ORGLTSPACE)i 
PTIDTAB*-! 

LNDi 

maxktabtau»max(maxptabta0«ptabtab)l 

»p0k(bluckstack»ptau1ablhtabtab#ptlklist|ptlkllst)) 

»oech(Cule:ve:l); 

fACTIUN(  i)t    ilNCHCCULEVEDJ 

$PUi>H(BLOCKSTACK,HTAbTABIPTABTAB#KTLKLISTlPTtKLIST)i 
iACTIUNC  4)1  STOKETYPE*INT  I 
SACTIUNC  5)1  iTOKtTYKt*LAB  > 
*ACTIUN(  6)1  iT0KtTYKE*80UL  t 

tAcTION(  o«  If  (ir  TEmP1«-S0PU(mS1ACK>N0W*PTT0I0TAB)«0 
THEN  TKUE 

ELSE  lUPDC I OTAb» TEMPI, LEVEL XCULEVEL) 
THEN  BElilN 

SEXLC(22)) 

ir  STORETYKL0LAB  THEN 

SCODE(KTA0TAB'STORETYPE*O#*QETSPACE}| 
»INCR(PTAHTAB) 
END 
ELSE  ERN0R(1«S0P0(MSTACK,N0H,EnTNY)}) 
SACTIONC  0)1  IF  SOPO(IUTAb*TEMPl»»OPD(MSTACK«NOM«PTTOIOTAH)»TYPE}a 

LAB 
THEN  IF  $OPO{IOTAb»TEMPl#LtVEL)»CULEVEL 
THEN  BEGIN 

»C00E(TEMP3»>0P0(I0TAB*TEMP1*PTT0ABTAB} 

«*»TOREAOO)I 
TEMPZt'SOPDClDTABfTEMPlfPTTOLKtlST)! 
WHILE  TEMP2#0  00 
BEGIN 

>CUOE(TEMPJ* 


6U 
61 

6^ 

6J 

)<4 

>d 

>6 

<f 

m 

)V 

'y 
'1 
'i 
'J 

'H 
'3 
'6 
f 
'0 
rv 
ttO 
SI 
0^ 
ttJ 

e« 

o» 

06 
0^ 

00 

ev 

9U 


-LJi;' 


»0PU(LKLIST#TEMK2#P1T0*bTA«)» 
•SETADDRUTHANSF  }l 
TtMP2»»0PD(LKLlST#TtMP2#LlNK) 

ENO> 

SOHU(lDTAB,TtMPl,FUUNU)»l 
E.ND 
LLSt    EHRUHC  J#$Of'D(MSTACK»NOH»ENTRY)) 
ELSE    tRKOKl«»»UKU(MSTACK»NOW»ENTHY))i 
SACTIUN(     9)1     IF    *OPD( IUTAtt#TEMKl«-»OPOlMSTACK#NOW«PTTOIOTAB)*TYPL)« 

LAB 
ThliN    BElilN 

If    »0PD(  lDTAB<TtMPl*rOUNt))»0    THEN 
BEGIN 

SPUSH(LKLIS1»PTT0ABTABIPTA8TAB» 

LINKI»OPt)<IDTAB#TEMPl#PTTOLKLIST))) 
»ENTEH(iOTAB»TEMPl#PTTOLKLISTlPTLKLlSl-l» 

U!>E0I1     )> 
scoot ( PI ABTA8t*ST0READ0H)i    SINCHC KT ABT Ab } 
ENOJ 
»COlJE($OPOCiOTAB.TEMPl,PTTOABTAB),«UTKANSF) 

ELSE    tKKORl«#$UPO(MSTAtK#NUH«ENTRY))i 
$ACTION(iy)l     sEMANTItTtST«-SOPD(lOTAB»»OPD(MSTACK#NUH*PTTOIOTAB)* 

TYPE)    ■    INT    I 
SACTION(ll)»    »C0UE{»UPi;(IUTAB»»UPU(MSTACK#PTMSTACK"3#PTTOIOTAB)» 

PTTOABTAB)»INT#*STORE); 
SACT1QN(U)|    If    lOPDUUTAb*  TEMPI  ♦»0P0  (MS  TACK#PTMSTACK-3#PTTUIDTAB)# 
TYPE)"BOOL 
THEN    SCUOE(SOPD(I0TAB#IEMPl«PTTOABTAB}fB0OI.«*ST0RE; 
ELSE    tRM0R(5*»0PD(MSTACK,PTMSTACK-3*ENTRY})i 


Vi! 

ys 
y6 

yo 

yy 

lUl 

10* 
1U» 
lUO 

10/ 
lUO 
lOV 


lU 

11 
u 
li 

14 

Id 
16 

u 

10 

ly 


im 
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5ACTIjN(lJ)l     tPUbHCUSTACKlPTAHTAb)i 

4C0UE(P1AbTAb#*ST0HtADDH»0.*CTRANSr); 
ilNCHCPT AUTAb)) 
«AtTlUN(14)i  »POK(  IFbTACKITEMHlJi  TEMK^i-KT  AB  T  AH*  1  ; 

tC0UE(PTAbTAb#*STUHtAUDH»0,*UTRANSF»TEMf'2#*STUKEA0UR» 

TLMP2»lEMPl»*bLTADURCTRANSF)l 
»HUi>H(IfSTACKlPTAHTAt!)J     »lNCR(PTAbTAb); 
tACTIjN(i3)i    *C0UE(P1AdTAb.*STUKtA0DK»PTABTAB#»UP0(lFSTAtK*N0H)# 
♦S)E1  AUOROTKANS>  )  J 
»POP( IFbTACK)) 
SACTIUN( 16)1     JC0Ut(»iDPD(MSTACK»PTMSTACK-2» ENTRY )}i 
SAcTIQNdOt     iCOtjE(»UPU(  I  UT  AB.  SUPUC  MST  AcK  »  NOW/PTTUl  OTAB  >  » 

PTTOABTAB))! 
SACTIUNdeji     iF    TtMPl*»OPl>(MSTACK»NOW*NUMBEROK)»0 
THEN    bElilN 

»EXtC(Z2)J 

»0PU(BIGTAb#TEMP2,NUMBER0K)*li 

tCOl}E(PTABTAB«INT« 

S0PI}(BIQTAB«TEHP2«1#ALI.}« 
*GETSPACE#PTABTAB)I 
»INCR(PTABrAB) 
ENU 

ELSE  »CU0E(S0PD(IUTAB#»0PU(MSTACK#N0H#PTTU1DTAB)# 
PTTOABTAB))! 

»ACTI0N(1V)|  IF  SOPD(IUTAB»TEMHI*»OPO(MSTACK*NOW»PTTOIDTAB)*TVPE)« 

BOOL 
THEN  »C0DE(S0PD(IUTAB«1EMP1*PTT0ABTAB)} 
ELSE  ERH0R(5#»(JPD(MSTACK,N0W»ENTHY))i 

>ACTI0N(2O}t  SC0UE(1)> 

SACTI0N(2ni    SCOUECOn 

»ACTI0N(22)I  »0PU(BI6TAB#TEMP2*10PD(MSTACK,N0H#ENTRT)/FTT01DTAB)» 


lul 


PTIUTAHI 


kt'UbHC  JUTAB'KTTOHIliTAaiTtMPi;* 
OACKPT      iTtMPl, 
HTTOAHTAb  IPIABTAB* 
LEVEL      ICULEVEL. 
lYPE        iSIORtTYPE, 
KEST        10  ) 


13rd 

ld> 
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APPENDIX  E 
OUTPUT  PRODUCED  BY  THE  ISL  TRA.NSLATOR 
ON  THE  SEMANTICS  OF  DEMALGOL  I  -  PASS  1 
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ABSTRACT 


j  It  is  well  known  that  a  Translator  Writing  System  (TWS)  can,  in 

'  general,  be  divided  into  two  parts:   a  syntax  preprocessor  and  a  semantics 
preprocessor,  yielding  compilers  composed  of  a  syntactic  recognizer  and 
a  package  of  semantic  routines.   This  paper  describes  the  semantic  pre- 
processor of  a  TWS.   Semantics  is  specified  as  a  program  written  in  a 
I  special  purpose  language  called  ISL  which  is  basically  an  extension  of 
I  ALGjZ^L.   The  extensions  include  some  constructs  often  needed  in  the  descrip- 
j  tion  of  semantics  of  a  language,  such  as  stack  and  table  declaration 
1  and  manipulation,  and  control  words  to  automate  to  a  great  extent  the  use 
of  the  TWS.   The  structure  and  use  of  ISL  are  described  and  an  example  of 
'  the  use  of  ISL  to  specify  the  semantics  of  a  small  subset  of  ALGjZ!)L  is 
I  presented  and  discussed. 
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